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'Lastly,  I  stand  ready  with  a  pencil  In  one  hand,  and  a  sponge  In 
the  other,  to  add,  alter,  Insert,  expunge,  enlarge  and  delete, 
according  to  better  Information.  And  If  these  my  pains  shall  be 
found  worthy  to  pass  a  second  Impression,  my  faults  I  will  confess 
with  shame,  and  amend  with  thankfulness  to  such  as  will 
contribute  clearer  Intelligence  unto  me" 

Preface  to  'The  History  of  the  Worthies  of  England' 

Thomas  Fuller  (1662) 

Such,  as  technical  author  of  the  Official  Handbook  of  Mascot  Version  3.1,  has  been  my  attitude  over  the 
past  two  and  a  half  years  to  the  scientific  worthies  of  the  Mascot  3  Definition  Team;  albeit  my  pencil  and 
sponge  are  of  an  electronic  variety.  Some  sections  of  the  handbook,  having  stimulated  particular 
controversy  among  the  Team  or  having  been  more  than  normally  misunderstood  by  me  or  having  been 
especially  savaged  by  the  pre-publication  reviewers,  have  been  'found  worthy'  of  a  whole  long  series  of 
impressions.  But  it  has  all  been  well  worth  the  effort  from  my  point  of  view.  When,  in  1984, 1  commenced 
work  as  a  freelance  lecturer  and  writer,  I  could  hardly  have  expected  the  good  fortune  of  becoming 
involved  in  such  a  stimulating  and  rewarding  project.  I  am  grateful  to  all  concerned. 

I  would  like  to  express  my  thanks,  first  of  all.  to  the  Royal  Signals  and  Radar  Establishment  for  financing 
the  task  of  writing  the  Handbook  My  gratitude  is  specially  due  to  Ken  Hayter  and  Keith  Oliver  who  shared 
the  job  of  Technical  Authority  for  the  project  I  would  also  like  to  thank  the  Royal  Military  College  of 
Science,  and  particularly  Tony  Sammes  as  head  of  the  Computing  Science  Group,  for  performing  project 
administration.  To  the  members  of  JIMCOM  I  am  greatly  obliged  for  their  faith  in  ratifying  my  original 
appointment  as  author  and  for  their  forbearance  in  accepting  a  series  of  revised  target  completion  dates 
which  seemed  at  times  to  be  diverging  to  infinity.  I  would  like  to  thank  all  those  who,  in  the  course  of  the 
limited  public  review  of  the  draft  Handbook,  provided  helpful  comments  leading  to  clearer  exposition  and 
pointed  out  many  typographic,  grammalic  and  orthographic  errors. 

Finally,  to  the  members  of  the  Definition  Team  itself  and  especially  to  Hugo  Simpson,  Ken  Jackson,  Tony 
Riddiough  and  Bill  Taylor,  I  owe  an  immense  debt  of  gratitude.  Throughout  my  period  of  involvement  in 
the  work,  they  have  striven  to  communicate  their  ideas  to  me  and  to  correct  my  misconceptions  with 
unfailing  patience.  While  rightly  insisting  that  the  concepts  of  Mascot  3  be  presented  to  the  world  with 
technical  accuracy  and  appropriate  relative  emphasis,  they  have  allowed  me  to  take  full  responsibility  in 
matters  of  presentation  and  have  tolerated  my  occasional  stylistic  idiosyncrasy  with  commendable 
resignation. 

George  Bate 
Wantage,  May  1987 
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The  development  ot  complex,  computer  based  systems  poses  major  problems  to  the  people  involved. 
These  problems  encompass  both  managerial  aspects,  concerned  with  control  of  the  overall 
development,  and  technical  aspects  concerned  with  the  interaction  of  the  individually  designed 
components  of  the  system.  Mascot  otters  a  wide-ranging  and  homogeneous  approach  to  the 
development  of  such  systems.  It  provides  significant  contributions  to  the  solution  of  both  managerial  and 
technical  problems 

Historical  Background 

Mascot  was  originated  by  Ken  Jackson  and  Hugo  Simpson  over  the  period  1971  to  1975.  After  the  initial 
implementation  work  was  completed,  the  Royal  Signals  and  Radar  Establishment  (RSRE)  formed  the 
Mascot  Suppliers  Association  (MSA)  in  order  to  effect  the  transfer  of  Mascot  technology  into  industry. 
The  MSA,  which  consisted  of  individuals  from  several  companies  and  MOD  establishments,  produced,  in 
1978,  an  'Official  Definition  of  Mascot'.  This  document  described  what  came  to  be  known,  retrospectively, 
as  Mascot  1  and  provided  a  definitive  reference  for  implementors  and  teachers  of  Mascot  while  ideas  and 
methods  continued  to  evolve 

In  1980  a  sub  committee  of  the  MSA,  drawing  its  membership  from  the  following: 

Admiralty  Surface  Weapons  Establishment 

Royal  Military  College  of  Science 

Royal  Signals  and  Radar  Establishment 

Computer  Analysts  and  Programmers  (Reading)  Ltd 

Ferranti  Computer  Systems  Ltd 

GEC  Computers  Ltd 

Software  Sciences  Ltd 

Systems  Designers  Ltd 

drafted  a  much  more  comprehensive  presentation  of  the  Mascot  concepts  as  'The  Official  Handbook  of 
Mascot'  This  handbook,  which  was  reissued  in  1983,  constitutes  the  standard  reference  for  Mascot  2 
and  has  received  an  extensive  distribution  A  companion  volume  to  the  l'983  issue,  'Additional  Features 
to  Integrate  Mascot  with  Coral  66',  provides  a  formal  syntactic  description  of  a  set  of  extensions  to  the 
MOD  standard  programming  language  which  make  it  a 'suitable  vehicle  for  Mascot  applications.  This 
language  was  named  AF  Coral  2 

The  drafting  of  these  documents  was  one  of  the  last  actions  of  the  MSA  before  it  was  disbanded,  having 
achieved  its  major  objectives  Responsibility  for  maintaining  the  Mascot  standard,  in  so  far  as  it  is  intended 
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for  use  in  government  projects,  was  taken  over  by  the  Inter  Establishment  Committee  on  Computer 
Applications  (IECCA).  A  joint  committee  ol  the  MOD  and  the  Dol,  IECCA  is  composed  wholly  of  official 
representatives.  In  order  that  the  liaison  with  industry  and  the  computing  community  generally,  so 
successfully  initiated  by  the  MSA,  could  be  maintained  and  extended,  another  organisation,  the  Mascot 
Users'  Forum  (MUF),  was  set  up  in  1980.  Informal  symposia,  open  to  all  actual  and  potential  Mascot  users, 
suppliers  and  supporters,  are  arranged  by  the  MUF  and  some  80  official,  industrial  and  academic  bodies 
have  been  represented. 

To  provide  a  convenient  basis  for  the  continued  technical  development  of  Mascot,  IECCA  and  the  MUF 
formed,  in  1981,  the  Joint  IECCA  and  MUF  Committee  on  Mascot  (JIMCOM).  It  is  under  the  aegis  of 
JIMCOM  that  the  work  on  Mascot  3,  the  subject  of  this  present  version  of  the  Official  Handbook,  has  been 
carried  out.  This  new  Mascot  definition  has  been  developed  by  a  team  in  which  the  following  have  been 
principal  contributors: 

Lawrence  Collingbourne  (Systems  Designers  pic) 

Gerry  Docherty  (YARD  Ltd) 

Giles  Forster  (MOD  -EQC) 

Ken  Jackson  (Systems  Designers  pic) 

Tony  Riddiough  (Software  Sciences  Ltd) 

Hugo  Simpson  (British  Aerospace  pic) 

Bill  Taylor  (Ferranti  Computer  Systems  Ltd ) 

The  enormous  contribution  of  George  Bate  who  was  the  technical  author  responsible  for  translating  the 
ideas  from  the  development  team  into  a  consistent,  coherent  text  is  gratefully  acknowledged. 
Acknowledgement  is  also  due  for  the  support  of  RSRE.  Finally  the  contribution  of  the  people  who 
commented  on  the  draft  versions  of  the  Handbook  is  gratefully  acknowledged. 


This  Handbook  has  been  written  principally  for  the  benefit  of  users  and  potential  users  of  Mascot.  The 
presentation  is  therefore  broadly  tutorial.  However,  within  this  general  approach  an  attempt  has  been 
made  to  be  as  helpful  as  possible  both  to  the  implementors  of  Mascot  and  to  those  concerned  with 
assessing  and  evaluating  the  resulting  implementations.  There  are  three  major  sections.  The  first  of 
these  is  introductory,  providing  the  background  to  the  present  stage  of  Mascot  development  and 
presenting,  in  an  informal  manner,  the  main  innovations  of  Mascot  3.  Then  follows  the  Official  Definition 
which  is  the  essential  core  of  the  book.  It  contains  both  descriptive  passages  suitable  for  those  requiring 
an  overall  understanding  of  the  ideas  and  rather  more  formal  material  intended  to  be  used  for  reference 
purposes.  Finally,  there  is  a  section  devoted  to  guidance  in  the  use  of  Mascot.  It  is  of  course  only  through 
practical  experience  that  the  optimum  application  of  the  Mascot  3  features  will  emerge  but  the  advice 
given  here  reflects  the  rationale  upon  which  they  have  been  devised. 
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The  new  concepts  which  this  handbook  introduces  into  the  Mascot  philosophy  demand  an  extended 
technical  vocabulary  tor  their  description.  Devising  acceptable  and  consistent  terminology  has  not  proved 
easy.  There  are  a  limited  number  ot  possible  words  available  (it  we  reject  the  idea  ot  coining  entirely  new 
ones)  and  they  are  all  inseparable  from  their  existing  associations  in  both  technical  and  everyday  usage. 
The  importance  of  the  glossary  which  appears  at  the  end  of  the  handbook  can,  therefore,  hardly  be 
emphasised  too  strongly.  It  contains  definitions  of  all  the  Mascot  technical  terms.  In  order  that  the  reader 
will  be  aware  that  a  word  is  being  employed  in  s  precise  sense,  all  such  instances  are  signalled  throughout 
the  Definition  by  the  use  of  bold  type.  This  will  help  to  make  more  comprehensible  those  passages  in 
which  technical  terms  have  had  to  be  used  before  being  fully  explained  in  the  text.  It  will  be  advisable, 
even  for  those  already  familiar  with  earlier  versions  of  Mascot,  to  consult  the  glossary  regularly  while 
reading  through  the  handbook  for  the  first  time. 

The  only  other  typographical  convention  is  the  use  of  bold  Italic  for  text  which  would  otherwise  need  to 
be  in  quotation  marks.  Examples  include  identifiers  used  in  sample  program  fragments  and  names 
invented  for  the  syntactic  elements  of  the  design  representation  language. 

Mascot  designs  have  two  parallel  forms  of  representation:  graphical  and  textual.  The  former  presents  no 
problem  here.  Its  conventions  are  well  defined  and  are  summarised  in  an  appendix.  There  is  no  barrier  to 
their  standard  use  in  all  Mascot  applications.  The  textual  form,  however,  does  raise  difficulties.  The 
Mascot  tradition  of  programming  language  independence  is  retained  in  Mascot  3  even  though,  for  many, 
the  choice  in  the  past  has  been  'any  language  provided  it  is  Coral'  and  in  the  future  will  presumably  be 
'any  language  as  long  as  it  is  Ada*'.  Neither  of  these  languages  is  ideal  as  a  vehicle  for  expressing  the 
textual  form  of  the  Mascot  design  representation  though  either  will  serve  in  practical  use. 

The  solution  adopted  has  been  to  invent  a  design  representation  language  to  fulfil  a  twofold  purpose. 
First,  it  serves  here  to  define  and  explain  the  design  constructs  in  a  rigorous  and  consistent  manner  and 
can  be  used  for  a  similar  purpose  in  future  publications.  Second,  it  is  proposed  as  the  notation  in  terms  of 
which  practical  Mascot  3  designs  will  actually  be  devised  and  communicated.  While  it  is  very  desirable  that 
some  automatic  means  of  translation,  such  as  a  pre-processor,  should  be  made  available  for  mapping 
these  designs  into  particular  programming  languages,  there  is  no  implication  that  this  is  an  essential 
prerequisite  to  the  use  of  Mascot.  Experienced  programmers  have  long  recognised  that  the  language  'in 
which  they  program'  need  not  be  the  (more  or  less  inadequate)  implementation  language  which  has  to  be 
used  for  other,  often  non-tech nical,  reasons.  The  same  considerations  apply  here  and  the  sole  criterion 
must  be,  as  in  the  past,  that  the  concepts  described  in  the  Mascot  Definition  are  capable  of  being 
expressed  in  the  chosen  implementation  language. 

The  design  representation  language  is  broadly  Pascal-like  in  that,  where  a  suitable  Pascal  convention 
exists,  it  has  been  adopted  This  choice  was  made  partly  on  the  grounds  that  Pascal  is  widely  familiar  to 
the  international  computing  community  and  partly  because  of  its  use  as  the  base  language  in  the 
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development  of  the  NATO  preferred  programming  language,  Ada*.  The  syntax  of  the  language  itself  has 
been  defined  by  means  of  the  type  of  jyntax  diagrams  first  employed  by  Wirth  to  describe  Pascal.  The 
author's  experience  of  teaching  programming  languages  at  a  variety  of  levels  has  produced  a  strong 
conviction  that  such  diagrams  provide  the  best  available  means  of  combining  rigour  with 
comprehensibility.  A  complete  set  is  presented,  for  ease  of  reference,  in  appendix  A  which  also  presents 
the  syntax  in  BNF  together  with  an  index  to  the  Handbook  itself.  Where  differences  occur  between  the 
syntax  diagrams  used  in  the  text  and  the  corresponding  diagrams  in  Appendix  A,  those  in  the  appendix 
constitute  the  full  definition. 

*  Ada  is  a  registered  trademark  of  the  U.S.  Government  -  Ada  Joint  Program  Office 
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CHAPTER  1 


1.  INTRODUCTION 

Mascot  is  a  Modular  Approach  to  Software  Construction  Operation  and  Test  which  incorporates: 

a)  a  means  of  design  representation  . 

b)  a  method  for  deriving  the  design  , 

c)  a  way  of  constructing  software  so  that  it  is  consistent  with  the  design 

d)  a  means  of  executing  the  constructed  software  so  that  the  design  structure 
remains  visible  at  run  time 

e)  facilities  for  testing  the  software  in  terms  of  the  design  structure. 

Of  particular  importance  in  the  design  representation  is  the  ability  to  represent,  directly,  concurrent 
functions  and  the  data  flows  between  them.  An  equally  important  facet  of  the  method  is  the  fact  that 
individual  components  in  the  design  structure  are  de-coupled  from  each  other.  This  has  a  significant 
impact  on  both  the  design  method  and  the  testing  strategy  and  leads  directly  to  a  form  of  'component 
technology'  familiar  in  all  other  branches  of  engineering.  It  causes  a  design  to  be  expressed  as  a  structure 
(or  assembly)  of  interconnected  components  each  of  which  is  of  a  specific  type.  Thus  each  component 
type  has  its  own  characteristics  and  embodies  constraints  on  where  and  how  it  may  be  connected  to 
other  component  types  But,  and  this  is  a  critical  feature,  no  component  refers  directly  to  another 
component.  Such  interconnection  information  is  specified  in  a  separate  form  rather  like  an  engineering 
drawing. 

The  software  structure,  by  its  insistence  upon  decoupling,  also  has  a  significant  impact  upon  the 
components'  potential  for  re-use  and  specifically  makes  the  creation  of  test  systems  very  much  more 
straightforward. 

Mascot  can  be  and  has  been  used  in  a  wide  range  of  application  areas.  It  is  however  aimed  primarily  at 
real-time  embedded  application  areas  where  the  software  is  complex  and  highly  interactive. 

1.1  Structure.  Modularity  and  Management 

One  important  motivation  for  the  provision  of  modularity  stems  from  the  need  to  employ  a  team  of  people 
on  one  single  job.  In  such  circumstances  it  is  essential  that  each  member  of  the  team  can  be  allocated  a 
job  to  do  which  contributes  to  the  overall  success  of  the  project.  Many  modularity  schemes  have  been 
devised  to  address  this  problem.  Most  of  them  involve  creating  an  overall  design  and  then  carving  up  the 
design  into  chunks  which  can  be  allocated  to  an  individual  team  member.  A  key  feature  of  Mascot  is  that, 
because  the  design  is  expressed  as  an  interconnected  network  of  otherwise  independent  components, 
each  component  can  be  developed  in  isolation  from  the  others.  Then  the  developed  components  can 
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be  brought  together  into  assemblies  or  sub-assemblies  at  a  later  stage  in  the  secure  knowledge  that, 
because  the  interconnection  constraints  have  been  policed  during  development,  the  components  will  tit 
together  and  will  have  a  high  probability  of  working  together  correctly. 

Thus,  through  a  modularity  scheme  based  on  sound  and  secure  component  technology,  Mascot 
provides  not  only  the  basic  ingredients  for  sound  team  management,  but  also  allows  the  use  of  traditional 
approaches  to  engineering  management. 

1.2  Derivation  of  Mascot 

1.2.1  Historical  (see  also  the  Preface  to  this  Handbook) 

The  antecedents  of  Mascof  can  be  traced  back  to  the  period  1965  -1970.  During  this  time  the  originators 
of  Mascot  were  involved  respectively  with  the  development  of  control  programs  for  an  automatic 
computer  controlled  radar  and  a  multi-access  operating  system  for  the  control  of  on-line  experiments  in 
real  time,  and  the  in-service  maintenance  of  various  operational,  embedded,  real-time  RAF  systems.  This 
early  experience  in  tackling  the  problems  of  embedded  real-time  systems  culminated  in  the  successful 
development  of  a  large  air  defence  system.  It  was  during  this  last  project  that  the  originators  came 
together  and  began  to  investigate  the  possibility  of  creating  an  alternative  and  well  defined  method  of 
software  development.  These  investigations  led  to  Mascot. 

1 .2  2  Technical 

Much  of  the  motivation  behind  Mascot  lay  in  the  apparent  preoccupation  with  control-flow  design  which 
was  prevalent  in  the  late  60s  For  complex  real-time  systems  it  was  obvious  that  there  could  not  be  a 
unique  control  flow  design  which  satisfied  all  the  functional  requirements  because  of  the  highly 
stochastic  nature  of  the  inputs.  Therefore  the  originators  looked  to  their  training  as  electrical  engineers 
for  inspiration  Here  they  discovered  that  concurrency  was  a  key  feature  together  with  the  notion  of  data 
flow  or  information  flow  from  one  stage  to  another.  For  example,  in  a  radio  receiver  RF  signals  are 
amplified  by  the  RF  stage  and  the  output  is  detected  by  the  demodulator  stage.  The  demodulator  output 
is  fed  to  an  audio  amplifier  and  its  output  is  fed  to  the  loudspeaker.  Thus  there  is  the  notion  of  information 
flowing  from  one  (concurrent)  stage  to  the  next  and  the  very  important  concept  of  well  defined  interfaces 
between  stages  to  decouple  the  design  of  one  stage  from  the  next.  There  is  notion  of  control  flow 
because  each  stage  is  performing  its  own  special  function  all  the  time  Thus  this  model  of  analogue 
electrical  circuits  became  the  foundation  for  the  Mascot  design  representation  and  method  of  software 
construction 

From  the  outset,  the  originators  held  the  view  that  writing  sequential  programs  (or  modules)  was  not  a 
problem  -  or  rather  if  was  not  a  problem  which  Mascot  would  address!  Instead  Mascot  would  concentrate 
on  what  was  perceived  to  be  a  more  difficult  problem,  namely  that  of  representing  concurrency  and  data 
flow  m  embedded  real-time  systems 
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1.3.1  General 

One  of  the  key  problems  with  software  is  its  intangibility  and  this  is  especially  true  of  large  systems 
Hence,  a  way  of  describing  the  software  is  required  which  presents  just  sufficient  detail  for  the  purpose 
This  usually  involves  a  top-down  presentation  so  that  an  overall  view  can  be  given  at  first.  Further,  more 
detailed,  views  follow  until  the  lowest  level  of  detail,  which  is  usually  the  source  text  in  an  appropriate 
programming  language,  is  reached.  The  key  requirement  of  a  design  representation  medium  is  this  ability 
to  present  a  design  at  appropriate  levels  of  detail. 

In  Mascot  the  starting  point  was  to  represent  the  design  graphically  with  emphasis  on  the  presentation  of 
data  flow  and  concurrency  From  such  a  diagram  one  can  gain  an  overall  impression  of  what  each 
component  has  to  do  and  how  the  overall  functionality  of  the  software  system  is  achieved.  Also  from  the 
diagram  it  is  possible  to  write  down  an  equivalent  textual  representation  of  the  whole  system  structure 
and  of  the  individual  components  required  to  build  that  structure.  Then  the  other  details  of  the 
components  can  be  added  as  the  design  effort  proceeds.  Once  components  have  been  built,  test 
systems  can  be  created  in  which  the  components  can  be  tested  Finally  the  complete  design  structure 
can  be  built  for  system  testing. 

These  characteristics  are  evident  in  both  Mascot  2  and  Mascot  3  In  the  following  sections  we  describe 
first  the  Mascot  2  method  and  then  indicate  how  and  why  Mascot  3  differs.  A  fuller  introduction  to  Mascot 
3  design  representation  can  be  found  in  section  2  1  Here  we  merely  touch  upon  the  salient  features  of 
both  Mascot  2  and  Mascot  3  in  order  to  make  the  comparison  and  to  identify  the  motiviation  for  updating 
Mascot  2 

1  3.2  Mascot  2 

The  basic  notion  in  Mascot  is  that  the  flow  of  data  through  a  system,  from  input  sensors  to  output 
actuators,  is  controlled  solely  by  a  set  of  concurrent  software  processes  These  processes  are  known  as 
'activities'  and  are  separately  scheduled  by  a  run-time  system  usually  referred  to  as  a  Mascot  'kernel'.  Data 
enter  and  leave  the  system  through  'devices'  which  are  software  accessible  registers  in  the  hardware  with 
which  the  software  system  communicates  The  data  are  moved  around  the  system  and  transformed  by 
activities.  Mascot  activities  thus  need  to  co-operate  with  each  other  by  passing  data  but  they  are  not 
allowed  to  communicate  directly;  their  immediate  communication  is  with  special  modules,  provided  for  this 
purpose,  called  'Intercommunication  Data  Areas'  and  usually  referred  to  as  IDAs,  IDAs  are  passive 
components  which  exist  only  to  satisfy  the  intercommunication  requirements  of  activities  They  contain 
data  areas  which  are  completely  private  to  the  IDA  and  support  the  intercommunication  requirements  by 
providing  a  procedural  interface  which  can  be  used  by  activities  Thus  fhe  designer  can  design  in  terms  of 
concurrent  processes  which  are  purely  sequential  (ie  activities)  and  IDAs  which  are  passive  but 
encapsulate  the  interactions  between  the  activities 
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This  represents  a  significant  separation  of  concerns: 


-  activities  are  sequential  processes  concerned  primarily  with  perfoming  a 
single  function  and  communicating  with  a  (usually  small)  set  of  IDAs 


-  IDAs  contain  any  data  sharable  by  activities.  Access  to  the  data  is  provided  by  a 
procedural  interface  whose  constituent  procedures  must  ensure  the  integrity 
of  the  data  in  the  IDA  by  using  the  synchronisation  facilities  of  the  Mascot 
kernel. 

Two  distinct  classes  of  IDA  have  been  identified  in  Mascot:  the  'channel'  and  the  'pool'.  The  channel  is 
used  to  pass  data  between  activities  on  a  'producer/consumer'  basis.  Producer  activities  send  messages 
via  an  input  interface  and  consumer  activities  receive  messages  via  an  output  interlace.  There  can  be  a 
buffer  of  messages  in  a  channel  at  any  instant.  These  are  messages  which  have  been  sent  but  not  yet 
received  (ie  they  are  currently  in  transit).  This  property  of  a  channel  is  useful  in  relieving  the  consumer 
activity  of  the  necessity  of  running  in  synchronism  with  the  producer  activities 

The  pool  is  used  to  hold  data  which  may  need  to  be  referred  to  by  activities  and,  in  particular,  in  cases 
where  the  frequency  or  pattern  of  references  to  the  data  is  completely  independent  of  the  frequency  or 
pattern  of  operations  which  bring  it  up  to  date.  Thus  there  could  be  many  references  without  any  change 
being  made  to  the  data  or  the  data  might  be  changed  many  times  between  successive  references 

It  is  important  to  realise  that  Mascot  does  not  provide  a  specific  and  fixed  set  of  IDAs.  Facilities  are 
provided  for  a  designer  to  define  and  build  the  specific  types  of  IDAs  required  by  his  application. 

The  graphical  representation  used  tor  Mascot  2  is  known  as  the  ACP  (Activity,  Channel,  Pool)  Diagram 
An  example  is  given  below  together  with  a  key  to  the  symbols  used  Note  that  the  producer/consumer 
characteristic  of  channels  is  indicated  by  connecting  one  side  of  the  symbol  to  producer  activities  and 
connecting  the  other  side  to  the  consumer  activity.  The  direction  of  data  flow  is  indicated  by  the  arrow 
heads. 
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The  ACP  diagram  depicts  the  instances  of  the  activities,  channels  and  pools  required.  The  types  of  the 
components  can  also  be  depicted  on  the  ACP  diagram  (usually  by  enclosing  the  type  in  parentheses). 

As  mentioned  earlier  activities  do  not  reier  directly  to  IDA  instances.  Instead  they  are  defined  and  coded 
in  terms  of  the  set  of  IDA  types  with  which  they  need  to  communicate.  During  the  software  construction 
process  the  activities  are  created(ie  manufactured)  and  then  'connected'  (i.e.  assembled)  to  the  set  of 
IDA  instances  required  by  the  design  and  expressed  in  the  ACP  diagram.  The  unit  of  construction  in 
Mascot  2  is  the  'subsystem'.  This  is  merely  a  collection  of  activities  which  have  been  connected  to  their 
IDAs  at  the  same  time.  The  subsystem  is  also  the  unit  which  can  be  controlled  at  run  time  by  being 
started,  terminated,  halted  or  resumed.  This  provides  the  facility  for  evolving  a  Mascot  network.  The 
operational  network  consists  of  the  set  of  subsystems  which  have  been  'formed'  and  'started'.  By  forming 
new  subsystems,  terminating  old  subsystems  and  starting  the  new  subsystems  it  is  possible  to  change 
an  operational  system  as  time  passes 

1.3.3  Mascot  3 

Motivation  for  the  development  of  Mascot  3  has  stemmed  from  two  considerations.  First,  experience  of 
Mascot  2  in  practical  use  has  inevitably  revealed,  within  its  proper  province  of  application,  some  areas  of 
weakness  which  it  is  desirable  to  remedy.  Second,  the  emerging  prospect  ot  implementing  systems  for 
large,  multiprocessor  networks  has  brought  with  a  a  need  for  more  powerful  and  flexible  means  of  design 
expression  than  those  available  in  Mascot  2.  The  aim  has  been,  therefore,  both  to  consolidate  and  to 
extend  the  Mascot  method. 

Perhaps  the  most  significant  refinement  which  Mascot  3  brings  to  existing  Mascot  concepts  concerns  the 
manner  of  expressing  network  connections  Mascot  2  networks  are  formed  from  system  elements  which 
have  been  created  from  templates  held  in  a  constructional  database.  Every  activity  template  contains  a 
fixed  number  of  external  connections  each  of  which  is  expressed  as  a  reference  to  an  IDA  template.  An 
assembly  of  inert  activities  is  converted  into  a  network  of  communicating  activities  by  supplying  IDAs  of 
the  appropriate  type,  created  that  is  from  appropriate  templates,  to  store  information  and  control  its 
transmission  in  each  of  the  data  flow  paths.  The  choice  of  valid  network  configurations  is  thus  constrained 
by  a  type  checking  mechanism  based  on  the  fact  that  activity  templates  contain  direct  references  to  IDA 
templates  Such  an  arrangement  allows  much  greater  flexibilty  than  one  in  which  the  references  are  to 
specific  IDA  instances. 

Although  this  Masco)  2  style  of  expressing  design  definition  is  very  flexible  it  does  contain  one  major 
restriction,  namely  that  an  activity  template  depends  upon  IDA  templates  In  Mascot  3  this  dependency 
has  been  changed  so  that  the  inter-dependency  between  activities  and  IDAs  is  focussed  on  the  interface 
which  exists  between  them  This  interface  exists  implicitly  in  Mascot  2  and  consists  of  the  set  of  access 
procedures  implemented  m  the  IDA  In  Mascot  3  the  procedural  interface  is  specified  explicitly  and  is 
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called  an  'access  interface’.  Thus  in  Mascot  3  an  activity  template  is  specified  in  terms  of  its  requirement  to 
use  one  or  more  access  interfaces  A  component  derived  from  that  template  may  be  connected  to  a  set 
of  IDA  components  (derived  from  their  templates)  subject  to  the  condition  that  the  access  interfaces 
provided  by  the  IDA  are  those  required  by  the  activity. 

The  terminology  introduced  into  Mascot  3  to  describe  these  ideas  is  that  an  IDA  'provides'  an  access 
interface  at  a  “window'  and  an  activity  'requires'  an  access  interface  at  a  'port'.  Thus  activities  can  have 
several  ports,  as  indeed  they  could  in  Mascot  2.  However,  in  Mascot  3,  IDAs  can  provide  several  windows 
whereas  in  Mascot  2  an  IDA  could  provide  only  a  single  window. 

This  greater  degree  of  design  decoupling  provides  several  advantages  in  terms  of  design  expression 
and  eliminates  some  of  the  causes  of  inefficiency  in  Mascot  2  design.  First,  an  activity  may  be  connected 
to  any  IDA  type  provided  that  the  port  to  window  connectivity  constraint  is  satisfied  (ie  that  the  access 
interface  required  at  the  port  is  that  provided  at  the  window).  This  means,  for  example,  that  for  test 
purposes  an  activity  can  be  connected  to  an  IDA  which  is  of  a  different  type  from  the  one  to  which  it  is 
connected  in  an  operational  network. 

Second,  the  ability  of  an  IDA  to  provide  more  than  one  window  means  that,  in  Mascot  3,  a  channel  can 
provide  two  interfaces,  one  for  the  writers  and  one  for  the  readers.  The  same  idea  can  be  extended  to 
pools  where  a  set  of  access  interfaces  can  be  provided  each  encompassing  a  limited  capability 
corresponding  to  the  particular  requirements  of  the  activities  using  it  The  use  of  multiple  windows  by  the 
designer  is  also  valuable  in  identifying  how  the  functions  of  a  system  are  distributed  in  relation  to  the  IDA  s 
position  in  the  network 

A  third  major  advantage  concerns  the  freedom,  in  Mascot  3,  to  design  IDAs  which  provide  several 
windows  of  the  same  type.  Thus  a  special  significance  can  be  attached,  within  the  IDA,  to  any  ot  these 
windows.  For  example,  one  window  might  be  given  priority  over  the  others  or  actions  within  the  IDA  can 
be  made  dependent  on  the  location  of  the  caller  within  the  connected  network  The  ability  of  an  IDA  to 
provide  several  windows,  combined  with  the  decoupling  arising  from  separate  definition  of  the  access 
interface,  is  considered  to  be  one  of  the  key  contributions  of  Mascot  3. 

Another  major  departure  from  previous  Mascot  philosophy  is  the  adoption  of  hierarchical  structure  A 
Mascot  2  design  is  conceived  in  terms  of  a  flat,  data  flow  network  whose  nodes  consist  of  alternate  data 
processing  and  data  communication  elements.  While  higher  level  descriptions  may  be  used  in  the 
process  of  devising  the  network,  they  have  no  permanent  standing  and  are  not  recognised  as  design 
entities  by  the  supporting  constructional  database.  The  final,  essentially  two-dimensional  structure  may 
be  partitioned  into  an  arbitrary  patchwork  of  subsidiary  networks,  the  adjacent  members  of  which  share 
common  communication  elements.  These  are  the  Mascot  2  subsystems  which  subsequently  constitute 
units  of  control  at  run  time 
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In  Mascot  3,  the  role  of  the  subsystem  has  been  greatly  elevated.  While  it  continues  to  represent  a 
subsidiary  network,  it  no  longer  possesses  shared  components  but  may  be  used  as  a  network  node  in  its 
own  right.  As  such  it  is  capable  of  being  connected  to  either  processing  or  communication  elements  and 
so  may  perform  the  function  of  either  or  behave  as  a  mixture  of  the  two.  It  may  also  possess  lower  level 
subsystems  among  its  components  so  as  to  facilitate  an  hierarchical  form  of  design  expression.  At  the 
same  time,  with  appropriate  database  support,  it  makes  it  possible  to  develop  and  capture  a  design, 
progressively. 

The  modules  of  text  which  represent  subsystems  (and  systems)  in  the  Mascot  3  database  contain, 
between  them,  all  the  information  needed  to  establish  the  content  and  connectivity  of  the  complete 
network.  The  processing  of  these  modules,  supported  by  all  the  remaining  modules  which  define  the 
system,  leads  to  the  construction  of  a  template  from  which  a  complete  collection  of  application  software 
can  be  created  and  loaded  into  appropriate  locations  in  the  target  hardware.  They  thus  embody  all  the 
information  which,  in  the  Mascot  2  method  of  software  construction,  is  provided  at  the  stages  of  system 
element  creation  and  subsystem  formation 

Whereas  in  Mascot  2,  therefore,  the  connectivity  of  the  software  network  is  not  established  until  the  last 
stage  of  construction,  in  Mascot  3  it  is  established  as  the  first  stage.  The  advantage  of  the  Mascot  2 
approach  is  that  it  readily  supports  evolutionary  construction,  the  ability  to  make  adjustments  to  the 
network  without  regenerating  the  system  or  even  terminating  its  execution.  This  may  be  less  easy  to 
achieve  in  Mascot  3  but  a  compensatory  gain,  in  addition  to  hierarchical  design  expression,  is  the  facility 
of  validating  the  overall  design  structure  in  terms  of  the  inter  module  dependencies  before  any  detailed 
implementation  coding  has  been  submitted  to  the  database 

It  will  be  clear  from  the  earlier  discussion  that  a  Mascot  3  subsystem  is  a  composite  entity.  It  defines  a  set 
of  interconnected  components.  Most  other  design  elements  have  composite  as  well  as  simple  forms.  For 
example,  a  composite  IDA  defines  a  network  of  internal,  component  IDAs  This  is  made  possible  by 
another  extension  of  the  Mascot  philosophy  which  allows  IDAs  to  communicate  with  each  other  directly 
without  an  intervening  active  element.  Such  relatively  complex  constructions  are  particularly  useful  where 
the  IDA  is  required  to  control  communication  between  activities  located  in  different  parts  of  distributed 
hardware 

The  fundamental  notion  in  Mascot  2  that  activities  must  only  communicate  via  IDAs  is  retained  in  Mascot  3 
However,  because  Mascot  3  IDAs  can  have  ports,  it  is  possible  that  the  interaction  between  any  two 
activities  may  involve  more  than  one  IDA. 

The  concept  of  composite  templates  in  Mascot  3  extends  to  sequential  as  well  as  network 
decomposition.  An  ind'vidual  thread  of  execution,  an  activity,  may  be  composed  of  a  number  of 
separately  created  components  which  communicate  with  each  other  through  well  defined  procedural 
interfaces  These  components  share  with  the  simple  form  of  activity  the  ability  to  make  external  network 
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connections.  Since  the  components  may  themselves  be  composite  the  facilities  exist  for  hierarchical 
expression  of  this  level  of  the  design  also 

The  Mascot  model  for  device  handling  is  essentially  unaltered  in  Mascot  3.  It  is,  however,  catered  for  in  a 
more  formal  manner  by  the  provision  of  a  new  class  of  design  element,  called  a  server,  which  is  dedicated 
to  communication  with  hardware  devices.  It  is  similar  to  the  generalised,  Mascot  3  form  of  IDA  but  is  the 
only  design  element  which  communicates  with  devices  and  to  facilitate  this  is  allowed  to  contain  an 
interrupt  handler. 

1.4  Method 

In  Mascot  2  the  method  could  be  divided  into  three  phases: 

a)  Network  Design  -  which  created  the  ACP  diagram  and  identified  the  purpose 
of  each  component 

b)  Component  Design  -  in  which  each  component  was  designed  and  coded 

c)  Integration  and  Test  -  in  which  each  component  was  tested  first  individually 
and  then  in  conjunction  with  other  components 

In  Mascot  3  the  same  set  of  phases  can  be  identified  but  there  are  some  additional  tasks  within  each: 

a)  Network  Design  in  Mascot  3  is  an  iterative  process  involving  (potentially) 
the  creation  of  an  hierarchy  of  subsystems.  IDAs  and  servers. 

b)  Component  Design  in  Mascot  3  can  involve  the  decomposition  of  activities 
into  lower  level  components 

c)  Integration  and  Test  in  Mascot  3  is  similar  to  Mascot  2  except  that  it  must 
take  account  of  the  additional  levels  of  decomposition. 

1.5  Development  Environment 

The  Mascot  3  development  environment  is  far  less  specific  than  that  defined  for  Mascot  2  .  This  is 
primarily  because  Mascot  3  is  considered  to  be  more  capable  of  being  used  as  a  stand  alone  design 
method  than  Mascot  2.  An  important  contributory  factor  here  is  the  need  to  work  with  languages  such  as 
Ada  which  do  not  allow  the  intimate  integration  that  has  been  possible  with,  say,  Coral  66.  Therefore,  the 
Mascot  3  development  environment  has  been  defined  in  terms  of  a  set  of  functions  to  control  the 
progressive  capture  of  a  design.  These  functions  are  known  as  the  'status  progression  commands'  and 
allow  a  template  in  Mascot  3  to  be  first  'registered',  then  'introduced',  and  finally  'enrolled'.  These 
operations  work  primarily  on  one  specific  template,  but  they  also  require  a  specific  status  to  be  achieved 
by  other  templates  upon  which  that  template  depends. 
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The  execution  environment  of  Mascot  3  is  again  very  much  less  specific  than  for  Mascot  2  None  of  the 
facilities  specified  have  been  significantly  changed,  but,  in  recognition  of  the  existence  of  languages 
which  directly  support  concurrency,  the  Mascot  run-time  facilities  (ie  those  provided  by  the  Mascot  kernel) 
are  no  longer  mandatory. 
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2.1  AN  INFORMAL  INTRODUCTION 


2.1.1  Introduction 

This  part  of  the  Official  Definition  of  Mascot,  'Design  Representation',  contains  the  quintessence  of  the 
Mascot  approach.  It  is  the  portion  of  the  Handbook  to  which  those  familiar  with  the  earlier  (1981)  edition 
will  wish  to  give  closest  attention  in  order  to  gain  an  understanding  of  the  ideas  which  have  been 
developed  during  the  past  five  years.  An  attempt  has  been  made  to  present  these  new  concepts  with  the 
rigour  and  completeness  befitting  a  formal  definition  while,  at  the  same  time,  making  it  ag  easy  to  read  as 
possible.  Opinions  will  differ  as  to  how  successfully  these  objectives  have  been  attained  but  it  is  a  safe 
assumption  that  most  readers  will  find  some  of  the  material  relatively  demanding.  Hence  the  need  for  an 
informal  introduction 


The  exposition  in  this  section  is  neither  rigorous  nor  complete  and  should  not  be  taken  as  definitive. 
While  it  is,  of  course,  accurate  as  far  as  it  goes,  it  is  in  no  sense  a  substitute  for  the  sections  which  follow 
but  rather  is  intended  to  establish  a  framework  within  which  the  detail,  presented  later,  may  more  readily 
be  understood.  It  concentrates  on  the  simpler  aspects  of  each  topic  in  order  to  introduce  the  principal 
concepts  and  terms.  The  Definition  describes  a  set  of  facilities  judged  sufficiently  powerful,  in  their 
entirety,  for  use  in  addressing  the  design  of  extremely  complex  computer  systems.  Here,  however,  the 
more  complex  constructions  and  most  of  the  supplementary  features  are  omitted  in  the  interests  of 
displaying  the  essential  simplicity  of  the  underlying  ideas.  In  practice,  the  users  of  Mascot  will  adopt  as 
many  of  its  features  as  may  be  required  for  the  application  in  hand 


1.1.2  Design 


Representation 


The  architecture  of  Mascot  designs  is  expressible  in  two  equivalent  forms:  graphical  and  textual  Each 
one  may  readily  be  derived  from  the  other.  For  example,  a  design  which  is  conceived  and  developed  in 
the  graphical  form  may  be  transformed,  in  a  wholly  mechanical  manner,  into  the  textual  form  and  hence 
progressively  captured  in  the  Mascot  database  to  establish  the  structure  of  the  software 
Implementation  is  then  completed  by  specifying  details  of  the  interlaces  through  which  the  components 
of  the  system  communicate,  together  with  the  data  types  with  which  they  are  concerned,  and  by 
supplying  the  executable  code  expressed  in  whatever  implementation  language  has  been  adopted 
Alternatively,  a  system  might  be  designed  directly  in  the  textual  notation  and  the  graphical  form 
subsequently  derived  from  it  to  become  the  central  feature  of  its  design  documentation  and  to  provide  a 
primary  medium  of  discussion  for  everyone  involved  with  the  system  throughout  its  lifecycle 


One  of  the  prime  features  of  the  Mascot  method  is  concurrency  A  typical  design  defines,  in  an 
hierarchical  manner,  a  set  of  parallel  co-operating  processes  At  the  higher  levels  of  the  hierarchy  these 
parallel  threads  of  execution  are  bunched  together  in  constructional  units  called  subsystems 
Progressive  expansion  of  the  subsystems  separates  the  larger  bunches  into  smaller  ones  and 
eventually,  at  the  lower  levels,  teases  out  the  individual  threads  These  individual  units  of  concurrency  in 
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a  Mascot  design  are  known  as  activities.  They  are  executed  in  a  standard  run-time  environment 
provided  by  a  collection  of  context  software  whose  functions  are  implicitly  available  to  the  application 
software.  The  interface  between  the  context  and  the  application  software  is  expressed  in  a  form  which 
is  generally  compatible  with  the  style  of  the  application  software  modules  and  is  known  as  the  context 
interface. 

The  hierarchical  nature  of  this  structure  permits  the  design  to  be  viewed  at  various  levels  of  abstraction, 
examination  of  any  one  of  which  immediately  highlights  the  second  salient  feature  of  the  Mascot  design 
representation  This  is  data  flow  Each  level  of  the  design  is  conceived  as  a  network  through  which  data  is 
transmitted  from  one  active  entity  (subsystem  or  activity)  to  another.  The  ultimate  sources  and  sinks 
of  this  information  are  provided  by  a  set  of  hardware  devices  which  are  regarded  as  being  outside  the 
Mascot  system  but  with  which  communication  may  take  place  through  a  class  of  software  design 
elements  called  servers  which  are  dedicated  to  this  purpose. 


2.1.3  A  Sample  Outline  Design 

in  Section  5.1  of  the  Handbook  the  approach  to  the  development  of  a  Mascot  design  is  described  in 
detail.  For  our  purposes  here  we  will  suppose  that  a  design  has  already  been  completed  to  the  point  at 
which  the  overall  software  structure  has  been  established.  The  diagram  is  drawn  and  there  exists  in  the 
Mascot  database  a  module,  that  is  a  named  textual  representation,  for  each  of  the  design  elements 
that  has  been  used  Furthermore,  all  the  inter  module  references  have  been  checked  and  found  valid. 

We  are  not  concerned  with  what  our  imaginary  system  is  designed  to  do.  Identifiers  have  deliberately 
been  chosen  for  their  inherent  lack  of  meaning,  or  else  to  be  so  general  as  to  achieve  the  same  effect,  in 
order  that  there  shall  be  no  temptation  to  be  distracted  by  this  question.  This  would,  of  course,  be  as 
reprehensible  in  a  real  design  as  failing  to  use  meaningful  identifiers  in  a  sequential  program.  In  practice  it 
is  recommended  that  template  names  reflect  the  function  provided  by  the  template;  wheras 
component  names  should  reflect  the  purpose  of  the  component  in  the  network  which  contains  it. 
The  only  purpose  of  the  system  we  are  about  to  examine,  however,  is  to  demonstrate  aspects  of  Mascot 
design  representation  it  should  not.  in  particular,  be  taken  as  exemplifying  specially  recommended 
practice 

The  natural  place  to  begin  is  with  the  diagram  representing  the  top  level  of  the  design. 
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This  diagram  shows  our  example  system.  It  corresponds  to  what,  in  the  Mascot  method,  is  called  the 
'initial  design  response’.  It  shows,  on  the  outside  of  the  system,  the  set  of  hardware  devices  the 
system  is  required  to  interact  with  It  shows,  on  the  inside,  a  set  of  high  level  design  components  which 
represent  the  initial  design  of  the  system.  The  system  itself  is  symbolised  by  the  round  cornered 
rectangle  which  identifies  the  boundary  between  hardware  and  software  and  indicates  the  flow  of  data 
into,  out  of  and  within  the  system  in  very  broad  brush  terms.  The  name  of  this  particular  system  is 
example_sys  It  consists  of  five  communicating  components  three  of  which,  like  the  system  itself, 
are  symbolised  by  round  cornered  boundaries  and  represent  subsystems.  Throughout  the  Mascot 
graphical  convention  round  corners  generally  indicate  active  entities  and,  although  occasional 
exceptions  can  occur,  it  is  normally  safe  to  assume  that  a  subsystem  contains  at  least  one  of  the 
concurrent  threads  of  execution  which  constitute  the  active  constituents  of  the  system.  The  three 
components,  si,  s2  and  S3  may  therefore  be  thought  of  as  being  executed  in  parallel. 

The  two  remaining  components  of  system  example_sys  illustrate  the  feature  which,  more  than  any 
other,  distinguishes  Mascot  from  other  approaches  to  the  problems  of  large  scale  concurrency.  In  order 
that  asynchronously  executed  processes  may  exchange  information  in  a  secure  manner,  it  is  necessary 
to  provide  mechanisms  to  effect  mutual  exclusion  and  cross-stimulation  for  use  at  the  points  where  data  is 
transferred  to  or  from  common  storage  areas.  As  explained  inSection  4.2  of  the  Handbook,  failure  to  do 
this  may  lead  to  information  becoming  corrupt  and  failure  to  do  it  adequately  may  result  in  the  processes 
becoming  deadlocked.  In  many  approaches  to  the  organisation  of  parallel,  co-operating  processes,  these 
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fundamental  mechanisms  are  not  made  directly  available  by  the  run-time  system.  Instead,  a  set  of  higher 
level  operations/tacilities  such  as  monitors,  message  passing  or  rendezvous  are  provided.  In  Mascot  the 
view  was  taken  that,  in  order  to  obtain  the  optimum  performance  which  is  always  vital  in  in  embedded 
systems,  it  was  best  for  the  run-time  system  to  make  the  low  level  facilities  directly  available.  This  has  the 
advantage  of  making  the  run-time  system  small  and  efficient  It  also  gives  the  designer  freedom  to  design 
exactly  the  right  set  of  higher  level  operations  required  for  his  application.  The  design  entity  in  which  all 
these  requirements  are  satisfied  is  called  an  Intercommunication  data  area  or,  more  succinctly,  an 
IDA  It  is  the  responsibility  of  IDA  designers  to  implement  the  required  operations  as  access 
procedures  (or  functions)  within  an  IDA.  These  operations  use  the  low  level  synchronisation  facilities 
to  maintain  both  data  flow  and  data  integrity.  A  further  contribution  is  made  to  system  integrity  by  ensuring 
that  only  IDAs  contain  data  which  can  be  the  subject  of  interaction  from  several  acivltles  and  that  only 
IDAs  may  use  the  low  level  synchronisation  facilities.  The  most  general  form  of  IDA  is  represented 
graphically  by  a  rectangle;  sil  and  sl2  are  examples 

The  thin  lines,  beanng  arrow  heads,  which  link  the  subsystem  and  IDA  symbols  into  a  network  are  lines 
of  data  flow  known  in  Mascot  as  paths  Thus,  data  flows  from  subsystem  s2  to  subsystem  s3  along 
the  two  paths,  labelled  ack  and  rec  respectively,  which  enter  and  leave  the  IDA  sl2  In  IDA  sll  a 
merging  of  information  flow  occurs  with  paths  put  and  trans,  from  si  and  s3  ,  entering  and  path  slg 
to  s2  leaving  It  will  be  seen  that  in  one  instance  a  path,  get,  links  two  subsystems  directly  However, 
as  we  shall  discover,  this  does  not  reflect  any  failure  to  carry  out  the  necessary  synchronisation.  The 
concepts  of  both  paths  and  IDAs  will  be  discussed  in  greater  detail  later  when  our  example  system  has 
been  expanded  to  reveal  the  lower  levels  of  its  structure. 

We  shall  eventually  return  to  this  system  diagram  and  examine  the  module  (textual  unit)  which  is 
equivalent  to  it  For  the  moment,  leaving  some  of  its  detail  unexplained,  we  shall  consider  what  further 
information  is  needed  for  software  construction.  Obviously  it  is  necessary  to  know  how  to  create  the 
components.  A  pattern,  or  in  Mascot  terms  a  template,  is  required  for  each  of  the  three  subsystems 
and  two  IDAs  Consider,  for  example,  the  component  labelled  s3  The  identifier  subsys_3  which 
appears  inside  the  corresponding  symbol  is  the  name  of  the  template  from  which  this  subsystem  is 
created  Expansion  to  a  further  level  of  decomposition  reveals  the  graphical  representation  of  its  internal 
composition 
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It  will  be  seen  that  the  template's  external  connections  match  those  of  the  component  which  it 
describes.  Data  flows  into  the  subsystem  along  a  path  labelled  rec  and  out  along  paths  labelled  get 
and  trans,  respectively  All  three  of  these  paths  are  connected,  internally,  to  one  of  the  template's 
two  components,  s4,  which  is  immediately  recognisable  as  another  subsystem  The  second 
component,  called  sv  and  represented  by  a  D-shaped  symbol,  is  an  example  of  a  server  This  is  the 
design  element,  referred  to  earlier,  which  is  able  to  communicate  with  external,  hardware  devices  A 
device  is  represented  here  by  a  hatched  rectangle  joined  to  the  server  by  a  broken  line.  We  shall  return 
to  this  diagram  later  but,  for  the  present,  further  discussion  will  once  again  be  postponed  in  favour  of 
performing  one  more  level  of  decomposition.  In  order  to  show  what  is  required  for  the  creation  of 
component  s4,  it  is  expanded  to  reveal  its  template,  subsys_4 
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No  further  network  decomposition  is  possible  in  this  branch  of  the  hierarchy  The  components  of 
subsystem  subsys_4  include  two  individual  activities,  represented  by  the  two  large  circular 
symbols  labelled  al  and  a2  Activities,  as  already  indicated,  are  fundamental  processing  elements. 
Each  one  is  to  be  regarded  as  implementing  a  separate  parallel  thread  Any  further  analysis  of  them  can 
only  be  in  terms  ot  sequential,  rather  than  network,  decomposition 

The  template  subsys  4  also  contains  two  IDAs.  They  are  represented  by  slightly  modified  versions 
of  the  simple  rectangular  symbol  seen  earlier  in  the  system  diagram  This  shows  them  to  be  special 
cases  corresponding  to  the  channels  and  pools  of  previous  versions  of  Mascot.  The  channel  is 
characterised  by  a  destructive  read  operation,  data  flowing  through  it  is  temporarily  accommodated  in 
internal  storage  which  may  become  full  as  a  result  of  repeated  write  operations  or  empty  as  a  result  of 
repeated  read  operations  In  a  pool  it  is  the  write  operation  which  is  destructive  Its  contents  consist  ol  a 
collection  of  variables  which  are  given  initial  values  when  the  system  commences  execution  and  which 
may  subsequently  be  examined  and  updated 

2.1.4  The  Communication  Model 

Having  now  looked  bnefly  at  the  graphical  representation  of  these  three  hierarchically  related  leveis  of  the 
imaginary  design,  we  shall  now  consider  each  in  more  detail  For  this  purpose  it  will  be  convenient  to 
proceed  from  the  trwe- 1  level  upwards,  examining  the  modules  which  represent  the  various 
templates  as  we  qo  Hut  first  it  is  necessary  to  deal  with  a  topic  which  is  so  fundamental  to  Mascot  as  to 
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demand  separate  treatment.  So  far,  data  flow  through  a  network  has  been  taken  for  granted.  It  is  now 
time  to  examine  the  Mascot  communication  model  in  more  detail. 


The  fundamental  concepts  are  illustrated  in  the  diagram  below  which  shows  a  simplified  fragment  of  the 
subsystem  subsys_4. 


Here  we  have  the  simple  case  of  a  producer  activity.  a2,  supplying  data  to  a  consumer  activity,  al. 
The  IDA  (a  channel),  connected  between  the  two  activities  and  represented  by  a  modified 
rectangular  symbol  labelled  ch,  acts  as  a  temporary  repository  for  items  of  data  en  route  from  a2  to  al 
An  intermediate  storage  buffer,  together  with  coding  to  operate  on  it,  is  encapsulated  in  the  IDA.  ch 
might,  for  example,  contain  a  procedure  which  adds  an  item  of  data  to  the  buffer  and  a  procedure  which 
removes  items  from  the  buffer  It  is  in  the  coding  of  such  procedures,  known  as  access  procedures, 
that  the  mechanisms  for  effecting  cross-stimulation  and  mutual  exclusion  are  employed 

Procedures  encapsulated  by  IDAs  are  made  selectively  available  for  use  by  activities  through  the 
concept  of  windows  These  are  represented  graphically  by  the  small,  filled  rectangles  labelled  sw  and 
tw  which  appear,  each  at  the  end  of  a  path,  just  inside  the  boundary  of  the  IDA  symbol  A  window  of 
an  IDA  makes  externally  available  a  sub  set  of  the  interactions  which  the  IDA  is  able  to  provide.  The 
nature  of  the  interactions  provided  at  a  particular  window  matches  the  type  of  the  path  connected  to  it. 
This  is  indicated  on  the  diagram  as  an  identifier  labelling  the  path  Thus  sw  and  fw  are  connected  to 
paths  of  type  send  and  fetch,  respectively 

The  type  of  a  path  is  defined  in  a  module  called  an  access  Interface.  This  is  classified  as  a 
specification  as  distinct  from  the  templates  which  define  the  types  of  Mascot  components  such  as 
activities,  IDAs,  servers,  subsystems  and  systems  It  contains  sufficient  information  to  allow  the 
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corresponding  set  of  interactions  to  be  invoked  Typically  this  includes  procedure  headings  and, 
indirectly,  definitions  of  the  data  types  which  appear  in  their  parameter  lists.  The  types  of  the  two  labelled 
paths  in  our  subsystem  fragment,  for  example,  might  be  defined  as  follows: 

ACCESS  INTERFACE  send  ; 

WITH  flow_data  ; 

PROCEDURE  insert  ( item  :  flow_data )  ; 

END  . 

ACCESS  INTERFACE  fetch  ; 

WITH  flow  data  ; 

PROCEDURE  extract  (  VAR  item  :  flow_data  )  ; 

END 

The  WITH  clause  which  appears  in  each  of  these  modules  is  a  reference  to  the  common  source  from 
which  they  obtain  their  definition  of  the  data-type  flow_data  needed  in  both  of  the  access 
procedures.  This  is  provided  by  a  specification  known  as  a  definition  which  might,  in  this  instance, 
take  the  following  form: 

DEFINITION  flow_data  ; 

TYPE 

<low_data  =  RECORD 
END; 

END 

Definitions  are  the  means  by  which  other  Mascot  modules,  whether  representing  specifications  or 
templates,  share  data-type  definitions.  Oepending  on  the  particular  programming  language  being 
employed,  Mascot  implementations  may  impose  additional  rules  concerning  the  naming  of  definitions 
and  the  point  in  the  progressive  elaboration  of  a  design  at  which  they  are  required  to  be  present  in  the 

database. 


Coding  capable  of  implementing  procedures  Insert  and  extract  is  included  in  the  template. 
chan  t,  which  defines  the  IDA  ch  In  outline,  chan_  1  looks  like  this: 

CHANNEL  chan_1  ; 

PROVIDES  sw  :  send  ; 

fw  .  fetch  , 

ACCESS  PROCEDURE  insert  (  item  :  flow_data  )  ; 

END  ; 

ACCESS  PROCEDURE  remove  (  VAR  item  :  flow_data  )  ; 

END  ; 

fw  extract  =  remove 

END 

After  the  heading,  which  names  the  template,  a  PROVIDES  section  lists  all  the  windows  of  the  IDA, 
giving  each  a  name  and  a  type  which  relates  it  to  an  access  Interface.  The  procedures  which 
implement  the  interactions  specified  in  the  interfaces  are  identified  in  the  body  of  the  IDA  by  the 
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language  word  ACCESS.  Other  procedures  might  be  declared  in  the  template  together  with  data 
structures  such  as  the  storage  butter  and  its  associated  pointers  These  program  entities  would  all  be 
local  to  IDAs  (such  as  ch )  created  trom  the  template  and  inaccessible  to  all  other  components 


This  example  demonstrates  the  two  ways  in  which  the  correspondence  between  the  access 
procedures  and  the  window  specifications  may  be  established.  In  the  case  of  procedure  insert  the 
correspondence  is  established  implicitly  by  name  Procedure  remove,  on  the  other  hand,  is  explicitly 
identified  with  the  access  Interface  procedure  specified  as  extract  This  is  achieved  through  an 
access  equivalence  list  at  the  end  of  the  module.  Thus  while  simple  cases  can  be  dealt  with  simply,  an 
unrestricted  facility  exists  whereby  internally  defined  procedures  may  be  allocated  between  the 
windows  of  the  ID  A 

Returning  to  the  fragmentary  subsystem  diagram,  it  will  be  seen  that  each  of  the  two  paths  that  we 
have  been  discussing  connect,  at  the  ends  remote  from  the  IDA  windows,  to  small,  tilled  circles 
labelled  sp  and  Ip  respectively.  These  are  situated  just  inside  the  boundaries  of  the  two  activity 
symbols  and  are  known  as  ports.  They  are  the  means  of  expressing  the  requirement  of  an  activity  for 
the  interactions  specified  in  an  access  Interface  For  a  valid  network  connection  to  be  established 
between  a  port  of  one  component  and  a  window  of  another,  they  must  refer  to  the  same  access 
Interface  Appropriate  ports  are  specified  in  the  activity  templates  a_temp_2  and  a_temp  i 
as  follows 

ACTIVITY  a_temp_2  ; 

REQUIRES  sp  :  send  , 

END 


ACTIVITY  a_temp_1  ; 

REQUIRES  fp  :  fetch  ; 

END 

Thus  objects,  such  as  a2  created  from  a_temp_2,  contain  coding  to  invoke  the  interactions 
specified  in  access  Interface  send.  The  port  name  is  used  as  a  selector 

VAR 

val :  flow_data  ; 

BEGIN 

sp.insert(  val )  ; 

With  the  interconnections  as  described,  activity  component  a2  would,  by  this  means,  invoke 
execution  of  procedure  Insert  in  the  IDA  component  ch.  Similarly  activity  al  would  invoke 
procedure  remove  (recall  the  access  equivalence  list)  of  ch  by: 
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VAR 

next  flow  data  . 

BEGIN 

fp  extract;  next )  . 

Furthermore  the  flowdata  items  can  be  transmitted,  in  this  way.  from  one  activity  to  the  other  via  a 
butter  m  IDA  ch  which  is  not  directly  accessible  to  either 


ntainm 


These,  then,  are  the  principal  features  ot  the  Mascot  communication  model  All  the  internal  features  of 
template  subsys  4  should  now  be  understandable  from  the  diagram  which,  tor  convenience,  is 


In  addition  to  the  interactions  just  described  in  detail,  at  also  transfers  information  into  the  pool  pi 
along  a  path  of  type  pul  Each  of  these  internal  paths  has  a  port  at  its  activity  end  and  a  window  at 
its  IDA  end  Not.ce  that  m  this  example  data  in  some  paths  flows  from  a  port  to  a  window  and  in  others 
from  a  window  to  a  port  Data  flow  in  both  directions  along  the  same  path  is  also  possible 

All  the  remaining  connections  on  this  diagram  pass  through  the  subsystem  boundary.  They  represent 
the  externa'  dependencies  of  subsystems  created  from  this  template  As  we  have  seen,  the  external 
dependencies  of  activities  and  IDAs  are  expressed  as  ports  and  windows  The  same  is  true  of 
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subsystems  which  may  possess  both  ports  and  windows  This  one.  tor  example,  has  three  ports 
and  one  window  as  may  be  seen  more  clearly  in  the  higher  level  diagram,  representing  the  template 
subsys_3  ot  which  rt  is  a  component 

All  the  coding  of  a  subsystem  template  is  encapsulated  in  its  components  and,  consequently,  each 
of  the  template  s  ports  or  window  must  be  connected  directly  to  a  port  or  window  ot  its 
components  indeed  rt  is  reasonable  to  regard  the  specification  of  a  subsystem  port  or  window  as 
a  method  of  making  a  port  or  window  of  one  of  its  components  available  for  connection  outside  the 
subsystem  Th.s  is  illustrated  on  a  diagram  by  ’port  to  port'  and  'window  to  window'  connections 
Thus  the  window  gw4  of  '.p*1  get  on  the  boundary  of  subsystem  subsys_4  is  equated  to  the 
window  gw  o'  the  same  type  belonging  to  the  pool  pi  The  two  names  are,  of  course,  local  to  their 
individual  templates  and  arbit'amy  chosen  Their  types,  however,  must  refer  to  the  same  access 
Interface  it  the  equiva'em-  ■•£  to  be  \a.;d  Similarly  each  of  the  three  ports  of  subsys_4  echoes  a 
port  of  the  same  \pe  bed  -,p  tc  or-e  of  its  component  activities 

Remembering  that  the  program  coding  for  our  imaginary  design  has  not  yet  been  written,  we  will  now 
examine  some  ot  the  modules  from  the  Mascot  database  which  represent  the  templates  and 
specifications  we  have  been  discussing  in  their  graphical  form  We  will  begin  with  a_temp_2,  the 
template  from  which  a2  is  tc  be  created 

ACTIVITY  a  temp  2  , 

REQUIRES  sp  send 
otp  out  . 
rp  rec 

END 

The  local  declarations  and  the  prog-am  coding  which  implements  this  thread  of  execution  will  eventually 
be  added  after  the  three  port  specifications  The  external  interactions  of  objects  created  from  the 
template  are  limited  to  those  specified  in  the  access  Interfaces  send  out  and  rec  to  which  it 
refers  The  corresponding  specifications  take  the  form  illustrated  earlier  (tor send  and  fetch  )  and  so 
need  not  be  included  here 

The  channel  template  chanl  which  depends  on  another  access  Interface  fetch  is 

represented  textuaily  as  follows 

CHANNEL  chan  1  , 

PROVIDES  sw  send, 
tw  fetch  . 

END 

When  the  contents  ot  thr  specifications  send  and  fetch  have  been  completed,  access 
procedures  and  private  data  storage  can  be  added  to  chan_1  and  correspondence  established 
between  me  procedures  and  the  various  interactions  provided  at  the  Wlodows 
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The  existence  in  the  database  of  access  interfaces  put,  trans  and  get,  together  with  any 
necessary  supporting  definitions,  permits  the  external  dependencies  ot  the  remaining  template 
modules  to  be  validated  in  the  following  form: 

ACTIVITY  ajemp  1  ; 

REQUIRES  fp  fetch  ; 

tp  trans  ; 

PP  Put  ; 

END 

POOL  pooM  ; 

PROVIDES  pw  put  ; 

gw  :  get  : 

END 

We  are  now  in  a  position  to  inspect  the  template  text  of  subsys_4  itself  it  is  presented  below  in  its 
entirety. 


SUBSYSTEM  subsys_4  : 

PROVIDES  gw4  get  , 

REQUIRES  rp4  :  rec  . 

otp4  :  out  , 
tp4  :  trans  , 

USES  pooM.  chan_1,  a_temp_1,  a_temp_2 
POOL  pi  pooM  , 

CHANNEL  ch  chan_1  . 

ACTIVITY  ai  :  attemp  t  (fp  =  ch  fw, 

tp  =  tp4, 
pp=  pi  pw  )  : 

ACTIVITY  a2  a.temp  _2  (  sp  =  ch.sw, 

otp  =  otp4, 
rp  =  rp4  )  : 


gw4  =  pi  gw 

END 

After  the  module  heading,  which  establishes  the  template's  name,  comes  what  is  known  as  the 
specification  part  This  defines  the  dependency  of  this  module  on  the  existence  ot  a  number  of 
access  Interfaces  in  other  words  rt  specifies  the  subsystem's  ports  and  window  The  features  ot 
this  part  should,  by  now,  be  entirely  familiar 


Then  follows  what  is  known  as  the  Implementation  part  This  is  something  new  because  none  of  the 
modules  we  have  examined  earlier  con'ain  any  implementation  It  starts  with  a  USES  section  which  is 
simply  a  list  of  all  the  templates  needed  to  create  the  components  of  this  subsystem  There  is  one 
for  each  activity  and  one  for  each  of  the  IDAs  and  we  have  already  examined  all  four  of  them  After  the 
USES  section  the  following  four  lines  of  the  module  specify  what  components  are  to  be  included 
and  how  they  are  to  be  connected  together 
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There  are  to  be  two  IDAs  called  pi  and  ch  created  from  templates  pool_1  and  chan_1, 
respectively.  Examination  of  these  two  templates  shows  that  the  resultant  components  each 
possess  two  windows  which  may  be  referred  to  as  pi. gw,  pl.pw,  ch.sw  and  ch.fw  The 
connectivity  of  the  network  is  established  by  using  these  window  references  in  the  specifications  of 
the  activity  components  which  follow  on  the  next  two  lines  of  the  module.  These  indicate  that  there 
are  to  be  two  activities  called  al  and  a2  created  from  templates  a_temp_l  and  a_temp_2 , 
respectively 

The  lists  in  parentheses  define  the  network  connections  by  means  of  the  'formal  =  actual’  convention. 
The  port  names  on  the  left  of  the  equivalences  (tp,  tp  and  pp  in  the  case  of  a_temp_1  )  are 
analogous,  in  this  context,  to  the  formal  parameters  of  a  procedure.  The  corresponding  'actual 
parameters'  specify  the  points  in  the  network  to  which  each  port  is  to  be  connected.  Where  the 
connection  is  direct  to  an  internal  window,  a  reference  to  that  window  is  given  in  the  form  indicated 
above.  Where  there  is  a  'port  to  port'  connection  passing  out  of  the  template,  the  name  of  the 
appropriate  port  on  the  boundary  of  the  subsystem  is  given.  Thus,  in  the  specification  of  activity  al, 
the  connections  are: 

port  tp  < . >  window  ch.fw 

port  tp  of  al  < . >  port  tp4  of  template 

port  pp  < . >  window  pl.pw 

and  in  the  specification  of  activity  a2  : 

port  sp  < . >  window  ch.sw 

port  otp  of  a2  < . >  port  0tp4  of  template 

port  rp  of  a2  < . >  port  rp4  of  template 

This  caters  for  all  the  network  connections  apart  from  the  single  '  window  to  window'  case.  The  last  line 
of  the  module  takes  care  of  this  by  equating  the  subsystem  window  with  that  named  gw  belonging 
to  the  IDA  pi  Thus  'port  to  port'  and  '  window  to  window'  connections  are  dealt  with  differently  in 
subsystem  templates.  The  former  are  handled  through  the  activity  'parameter  list'  and  the  latter 
through  equivalence  statements. 

2.1.6  A  Subsystem  Containing  Another  Subsystem  and  a  Server 

We  are  now  in  a  position  to  consider  the  template  text  of  subsys^3  which  utilises  subsys_4  to 
create  one  of  its  components  Here,  again,  is  the  diagram: 
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The  template  for  the  second  component  of  this  subsystem  in  its  partially  completed  state  is: 

SERVER  serve_1  ; 

PROVIDES  otw  out 
END 

Servers  are  closely  related  to  IDAs  The  main  difference  is  that  they  provide  means  of  interaction  with 
peripherals.  Consequently,  as  well  as  access  procedures,  which  can  be  invoked  by  activities 
connected  to  an  appropriate  window,  servers  may  also  include  handlers.  These  are  sections  of  code 
which  can  be  connected  to  hardware  interrupts  and  which  are  entered  for  execution,  on  a  pre-emptive 
oasis,  whenever  the  appropriate  interrupt  occurs.  The  function  of  the  handler  is  typically  to  control  data 
transfer  and  the  operation  of  a  hardware  device.  Transfer  between  the  buffer  and  active  Mascot 
components  such  as  activities  and  IDAs  is  achieved  in  the  normal  way  via  a  path  connected  to  a 
window  of  the  server  This  particular  server  template  specifies  a  single  window,  otw,  which  is  of 
type  out 


We  have  now  looked  at  all  the  templates  needed  for  the  components  *of  subsys_3  .  Here  is  the 
template  of  this  subsystem: 
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SUBSYSTEM  subsys_3 


PROVIDES  gw3  ;  get ; 

REQUIRES  rp3  rec, 
tp3  :  trans  ; 

USES  subsys_4,  serve_1  ; 

SERVER  sv  :  serve_1  ; 

SUBSYSTEM  s4  :  subsys_4  (  rp4  =  rp3, 

otp4  =  sv.otw, 
tp4  =  tp3  ); 

gw3  =  s4  gw4 

END 

This  should  readily  be  understandable  in  the  light  of  our  earlier  discussion  of  template  subsys_4 . 
The  specification  part  specifies  a  window  and  two  ports  in  terms  of  access  interfaces  get,  rec 
and  trans  all  of  which  we  have  already  considered.  The  Implementation  part  lists  the  required 
component  templates  before  specifying  the  two  components  and  their  interconnections.  There  is 
to  be  a  server  called  sv  created  from  template  serve_1  and  a  subsystem  called  s4  created  from 
template  subsys_4  The  connections  to  the  ports  of  s4  are. 

port  rp4  of  s4  < . >  port  rp3  of  template 

port  otp4  < . >  window  sv.otw 

port  tp4  of  s4  < . — >  port  tp3  of  template 

The  equivalence  statement  connects  the  window  gw4  of  the  component  subsystem  s4  to  the 
window  gw3  of  the  template 
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Finally  in  our  tour  of  this  imaginary  design,  we  return  to  our  starting  point:  the  system  diagram. 


A  module  to  represent  a  system  template  is  very  similar  to  one  for  a  subsystem  There  are. 
however,  no  external  network  dependencies.  In  other  words  a  system  does  not  specify  any  ports  or 
windows  On  the  basis  of  what  we  have  already  learned,  and  assuming  the  existence  of  the  necessary 
additional  supporting  templates  and  specifications,  it  is  easy  to  understand  system 
example_sys 

SYSTEM  example_sys  ; 


USES  subsys_1,  subsys_2,  subsys_3,  sida_1,  sida_2 
IDA  sil  :  sida_J  ; 

IDA  si2  :  sida_2  ; 

SUBSYSTEM  s2  .  subsys_2  (  sp2  =  sil  sw, 

ap2  =  si2.aw ) ; 

SUBSYSTEM  S3  :  subsys_3  (  tp3  =  sil.tw, 

rp3  =  si2.rw  )  ; 

SUBSYSTEM  si  :  subsys_1  (  ppl  =  sil.pw, 


END 


gpl  =  s3.gw3  )  ; 


2.1  Informal  Introduction 


2-  16 


Mascot  Version  3.1 


In  this  informal  survey  of  the  features  of  the  Mascot  scheme  of  design  representation  we  have  discussed 
the  function  of  ports,  windows  and  paths  and  examined  examples  of  two  kinds  of  specification 
(access  Interfaces  and  definitions)  and  five  kinds  of  template  (activities,  IDAs,  servers, 
subsystems  and  systems).  This  selection  corresponds  roughly  to  the  set  of  features  in  the  mandatory 
subset  of  the  definition  Study  of  the  full  definition  will  reveal  many  extensions  to  these  basic  concepts 
and,  in  particular,  the  optional  availability  of  composite  forms  of  most  of  the  templates  and 
specifications  presented  here  in  their  simple  form 


2/1.8  A  Composite  Activity 

A  composite  module  is  one  which  is  further  decomposed  in  terms  of  lower  level  modules.  Systems 
and  subsystems  clearly  come  into  this  category.  They  do  not,  in  themselves,  introduce  coding  but 
merely  describe  a  set  of  related  components.  Composite  forms  of  activities,  IDAs  and  servers  are 
described  in  the  following  sections  To  complete  this  introduction  we  will  look  at  just  one  of  these  forms: 
the  composite  activity  This  is  chosen  because  it  exemplifies  sequential  decomposition  rather  than 
the  network  decomposition  which  we  have  already  seen  An  activity  whose  implementation  is  complex 
may  be  designed  as  a  set  of  components  which,  in  the  executing  system,  communicate  via  procedural 
interfaces  The  Mascot  design  representation  provides  both  graphical  and  textual  conventions  to 
describe  this  form  of  construction 
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This  is  the  lowest  level  of  the  hierarchy  that  we  have  so  far  visited.  The  modification  is  that  the 
component  symbol  al  has  been  drawn  with  a  thick  boundary  like  that  for  the  subsystem.  The 
implication  is  that  the  corresponding  module  is  a  composite  one.  To  investigate  its  structure  we  must 
expand  the  symbol  to  reveal  a  lower  level  template  diagram. 


The  coding  of  component  al  is  to  be  divided  into  four  separately  developed  modules.  One  of  them, 
labelled  r  is  a  design  element  known  as  a  root.  Every  composite  activity  contains  exactly  one  root 
as  this  is  the  component  which  contains  the  initial  entry  point  of  the  coding.  This  particular  root  is 
created  from  a  template  called  main  which  in  turn  possesses  a  port  of  type  trans  connected,  via  a 
port  to  port  connection,  out  through  the  boundary  of  the  activity  template 

The  other  three  components,  sul,  su2  and  su3  are  subroots  created  from  templates  subl, 
sub2  and  sub3  respects  >ly  These  are  essentially  collections  of  procedures  and  a  composite 
activity  may  possess  any  number  of  them  Their  relationships  with  the  root  and  with  each  other  are 
represented  graphically  by  lines  bearing  hollow  arrow  heads  and  known  as  links.  They  indicate  here  that 
r  calls  procedures,  directly,  in  each  of  the  subroots  and  that  sul  and  su2  both  make  calls  on 
procedures  in  su3  Just  as  the  types  of  paths  in  a  network  take  the  textual  form  of  access 
Interfaces,  so  link  types  are  represented  in  the  Mascot  database  by  specifications  called 
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subroot  interfaces  Here  is  one  of  the  three  needed  for  the  new  version  of  template  a_temp_l  : 
SUBROOT  INTERFACE  sit  ; 

END 


The  contents  of  such  modules,  when  complete,  will  be  similar  to  those  of  access  Interfaces. 
Principally,  they  are  used  to  specify  the  headings  of  procedures  which  subroots  make  available  to  the 
root  and  to  other  subroots 


We  can  now  examine  the  template,  main,  from  which  the  component  r  is  created. 

ROOT  main  ; 

REQUIRES  t  :  trans  ; 

NEEDS  si  sil  ; 

s2  :  si2  , 
s3  :  si3  ; 

END 

The  port  is  specified  exactly  as  in  a  simple  activity.  The  NEEDS  section  specifies  the  links  which  are 
connected  to  components  of  this  type  in  terms  of  the  subroot  interfaces.  Coding  will,  of  course,  be 
added  to  this  module  before  the  final  END. 


We  now  turn  to  the  template,  subl,  for  component  sul  This  is  a  subroot  possessing  a  port 
together  with  links  both  entering  and  leaving, 

SUBROOT  subl  ; 

REQUIRES  p  :  put  ; 

GIVES  Sil  ; 

NEEDS  S  :  Si3  ; 

END 

The  new  feature  here  is  the  GIVES  section,  it  specifies  the  subroot  Interface  which  this  subroot 
implements  Every  subroot  implements  precisely  one  such  Interface. 


Template  sub3  which,  however,  possesses  no  ports  and  no  outward  going  links.  It  provides 
procedural  interactions  but  does  not  make  use  of  any. 


We  have  now  examined  all  the  specifications  and  templates  that  are  needed  for  the  design  of  the 
composite  activity  al  Here,  in  its  complete  form,  is  the  template  a_temp_l 
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ACTIVITY  a_temp_1  ; 

REQUIRES  fp  :  fetch  ; 

tp :  trans  ; 
pp  :  put  ; 

USES  main,  subl,  sub2,  sub3  ; 

SUBROOT  su3  :  sub3  ; 

SUBROOT  sul  :  subl  (  p  =  pp, 

s  =  su3 )  ; 

SUBROOT  su2  :  sub2  ( f  =  fp, 

s  =  su3  )  ; 

ROOT  r :  main  (  t  =  tp, 

si  =  sul, 
s2  =  su2, 
s3  =  su3  )  ; 

END. 


Following  the  specification  part,  identical  with  that  of  the  earlier  version,  comes  the  Implementation 
part.  This  begins  with  a  USES  section  which  lists  the  root  and  subroot  templates  needed  to  create 
the  components.  Then  follows  a  specification  of  each  component  with  its  network  and  subroot 
connections.  The  former  are  all  port  to  port  connections  and  are  dealt  with  in  the  same  manner  as  in 
subsystems.  The  remaining  parameters  specify  which  subroots  implement  each  of  the  the  subroot 
Interfaces  specified  in  the  corresponding  NEEDS  sections. 


With  this  discussion  of  the  Mascot  facilities  for  the  sequential  decomposition  of  individual  threads  of 
execution  we  come  to  the  end  of  this  informal  introduction  to  the  Mascot  scheme  of  design 
representation  All  the  principal  concepts  have  been  discussed  and,  if  they  have  been  understood,  the 
formal  definition  which  follows  should  present  no  insuperable  difficulties. 
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In  the  remainder  of  this  chapter  all  the  design 
representation  features  of  Mascot,  mandatory 
and  non-mandatory,  are  discussed.  Together 
with  the  relevant  parts  of  Appendices  A,  D  and 
E,  it  constitutes  a  formal  definition  of  this  aspect 
of  the  method. 
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2.2  A  NOTE  ON  PRESENTATION  STRATEGY 


In  determining  the  order  in  which  topics  should  be  presented  in  this  part  of  the  Handbook  it  was 
considered  important  to  focus  particular  attention  on  the  subset  of  features  mandatory  in  any  Mascot  3 
implementation.  Not  only  are  these  features  presented  first  but  they  are  described  without  reference  to 
the  existence  of  the  remaining  features  which  make  up  the  full  definition.  As  a  consequence  of  this 
strategy  many  of  the  diagrams  defining  the  syntax  of  the  Mascot  design  representation  language  appear, 
in  the  first  few  sections,  in  a  simplified  form.  Where  this  is  the  case  the  simplified  diagram  has  been 
identified  as  such  by  means  of  a  rectangular  frame.  There  are  features  of  these  framed  diagrams  whose 
significance  may  not  be  immediately  clear.  These  include  the  apparently  gratuitous  use,  for  example,  of 
the  word  simple  in  the  name  of  a  syntactic  entity  or  the  employment  of  an  entity  which  expands  directly 
into  another.  These  matters  can  be  clarified  by  reference  to  Appendix  A.  The  mandatory  subset  is 
identified  from  the  full  set  of  Mascot  features  in  Appendix  E. 
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2.3  PATHS.  PORTS  AND  WINDOWS 


Description 

The  Mascot  method  addresses  the  problems  of  creating  application  software  which  consists  of 
collections  of  communicating,  parallel  processes  executed  on  processor  configurations  of  arbitrary 
complexity.  For  any  particular  Mascot  application,  the  software  design  is  embodied  in  a  set  of 
hierarchically  related  templates.  At  the  lowest  level  of  each  branch  of  the  hierarchy,  element 
templates  provide  patterns  for  fundamental  software  objects  capable  of  performing  either  a  data 
processing  or  a  data  communication  function  A  path  between  a  pair  of  these  entities  denotes  the 
existence  of  a  set  of  operations  (usually  involving  data  transfer)  provided  by  one  of  the  participants  for 
use  by  the  other  All  such  transactions  thus  involve  a  passive  component,  concerned  with  information 
storage  and  transmission,  and  an  active  component,  concerned  with  information  processing.  The  nature 
of  the  interactions  associated  with  any  particular  path  is  defined,  in  procedural  terms,  by  a  textual  unit 
(module)  called  an  access  Interface.  Thus  an  access  Interface  is  a  specification  defining  a  set 
of  operations,  implemented  by  the  passive  component  and  which,  when  invoked  by  an  active  partner, 
transmit  data  in  either  or  both  directions 


Data  type  definitions  and  constants  relevant  to  these  interactions  may  also  be  supplied  to  both 
participants  from  the  access  Interface  8y  associating  definitions  with  a  communication  route  in  this 
way,  conformity  with  the  semanhc  rules  of  strongly  typed  implementation  languages  is  made  possible  and 
consistency  of  usage  between  separately  created  communicating  objects  is  ensured  This  data-typing 
information  is  held  separately  in  another  kind  of  specification,  known  as  a  definition,  from  where  it 
can  be  incorporated  nto  those  access  Interfaces  which  require  it. 


Every  path  in  a  Mascot  network  is  connected  at  one  end  to  a  port  of  a  component  Ports  are  normally 
possessed  by  activities,  which  are  the  fundamental  processing  elements  of  a  Mascot  system,  and 
by  subsystems  which  may  fulfil  a  similar  role  at  a  higher  level  of  the  design.  They  may,  however,  also 
occur  in  the  fundamental  communication  element,  the  IDA  A  port,  as  specified  in  a  template,  is  a 
named  reference  to  an  access  Interface  It  expresses,  in  terms  of  the  access  interface,  a 
requirement  to  invoke  data  transfer  (and  other)  operations  vyhich  are  implemented  outside  the 
component  in  which  the  port  is  specified  Establishing,  in  the  specification,  the  type  of  the  port  to 
which  a  path  is  to  be  connected,  thus  determines  the  group  of  operations  which  are  required 

At  the  other  end  ot  each  path,  in  a  communications  component  (usually  an  IDA  or  a  subsystem 
performing  a  data  communications  role)  is  a  window  A  window  as  specified  in  a  template  is,  like  a 
port,  a  named  reference  to  an  access  Interface  it  specifies,  in  terms  of  the  access  Interface,  a  set 
of  operations  to  be  provided  These  operations  may  be  invoked  by  other  components  connected  to  the 
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window  Establishing,  in  the  specitication,  the  type  of  the  window  to  which  a  path  can  be  connected, 
thus  determines  the  group  of  operations  which  are  provided.  Notice  that  whereas  each  port  in  a 
network  is  connected  by  a  single  path  to  the  provider  of  the  interactions  which  are  required,  any 
number  of  paths  may  be  connected  to  a  window.  This  is  to  say  that  any  number  of  components, 
which  possess  matchingports,  may  invoke  the  interactions  provided  at  a  particular  window. 

Both  activities  and  IDAs  may  be  used  at  any  depth  within  an  hierarchy  of  subsystems.  In  the 
network  diagram,  a  port  may  therefore  be  separated  by  the  boundaries  of  a  number  of  enclosing 
symbols,  from  the  source  of  the  operations  for  which  it  expresses  a  requirement.  A  window  may  similarly 
be  separated  from  the  nearest  port  along  a  given  path.  In  these  circumstances,  the  requirement 
expressed  by  the  port  and  the  provision  expressed  by  the  window  are  propagated  along  the 
communicating  path  through  a  series  of  identical  ports  and  windows  established  in  the  higher  level 
constructs  . 

Graphical  Representation 

The  interactions  between  components  readily  lend  themselves  to  diagrammatic  representation  in  terms 
of  static  data  flow  networks  in  which  the  node  symbols  represent  either  individual  elements  or  lower 
level  networks  A  path  is  the  route  along  which  information  is  transmitted  from  one  particular  element 
or  network  to  another  Its  diagrammatic  representation  is  a  thin  line  connecting  the  two  symbols 
together  This  is  normally  labelled  with  the  name  of  the  access  Interface  which  constitutes  the  type  of 
the  path  and  carries  a  solid  arrow  head  to  indicate  the  direction  of  data  flow. 

put  get 

- »>  4 - - - 


*4 


exchange 


The  diagram  below  shows  an  active  component,  on  the  left,  connected  via  a  path  to  a  passive 
component,  on  the  right,  with  a  port  at  the  active  end  of  the  path  and  a  window  at  the  passive  end 


Thus  a  port  is  represented  in  a  Mascot  network  diagram  by  a  small  filled  circle  connected  to  a  line 
representing  a  path.  The  port  symbol  may  be  labelled  with  an  identifier,  unique  within  the  template 
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which  possesses  it,  which  is  used  to  distinguish  between  ports.  The  path  itselt,  as  we  have  seen,  is 
labelled  with  the  name  of  the  access  Interlace  which  defines  its  type  so  that,  from  an  external  point  of 
view,  a  port  represents  a  network  connectivity  constraint.  As  ports  may  function  as  either  sources  or 
sinks  of  data,  the  solid  arrow  head  which  indicates  the  direction  of  data  flow  may  point  either  away  from  a 
port  or  towards  it. 


On  a  Mascot  network  diagram,  a  port  symbol  is  placed  just  inside  the  boundary  of  the  template  or 
component  to  which  it  belongs 


put 


* 


In  cases  where  data  are  transmitted,  along  a  path,  across  one  or  more  boundaries,  the  port  symbol  is 
repeated  at  each  boundary  This  reflects  the  necessity  of  respecifying  the  port  in  the  text  of  each 

template 


Different  activities  at  the  same  or  different  levels  of  the  hierarchy  may  share  a  set  of  operations 
provided  by  a  common  source  The  diagram  may  be  simplified  in  such  cases  by  merging  the  paths  This 
is  illustrated  in  the  diagram  below  which  shows  two  activities  reading  data  from  a  common  source  and 
incorporated,  at  the  same  level,  within  a  subsystem. 
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Performing  the  operations,  defined  by  means  of  a  port  and  its  associated  access  Interface,  demands 
the  execution  of  code.  This  code  is  contained  in  the  passive  communication  element  of  a  Mascot 
system,  the  IDA,  and  is  executed  in  response  to  direct  invocation  by  one  of  the  active  processing 
elements.  On  occasions,  especially  where  distributed  processing  hardware  is  involved,  one  passive 
component  may  need  to  use  the  operations  implemented  by  another  in  order,  for  example,  to  propagate 
information  from  one  hardware  unit  to  another.  It  is  thus  necessary  that  communication  components 
should  be  permitted  to  possess  ports  so  that  this  type  of  requirement  may  be  met.  Despite  the 
presence  of  a  port  on  the  boundary  of  the  symbol  shown  below,  it  nevertheless  represents  a  passive 
component  and  consequently  is  drawn  with  square  corners. 


t 

_ 

trigger 

A  window  is  represented  in  a  Mascot  network  diagram  by  a  thin,  filled  rectangle  connected  to  a  line 
representing  a  path.  The  window  symbol  may  be  labelled  with  an  identifier,  unique  within  the 
template  which  possesses  if,  which  is  used  to  distinguish  between  windows.  The  path  itself,  as  we 
have  seen,  is  labelled  with  the  name  of  the  access  Interface  which  defines  its  type  so  that,  from  an 
external  point  of  view,  a  window,  like  a  port,  represents  a  network  connectivity  constraint.  As  windows 
may  function  as  either  sources  or  sinks  of  data,  the  solid  arrow  head  which  indicates  the  direction  of  data 
flow  may  point  either  away  from  a  window  or  towards  it. 

On  a  Mascot  network  diagram,  a  window  symbol  is  placed  just  inside  the  boundary  of  the  template 
or  component  to  which  it  belongs. 
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In  cases  where  the  operations  provided  transmit  data  along  the  path,  across  one  or  more  boundaries, 
the  window  symbol  is  repeated  at  each  boundary  This  reflects  the  necessity  of  respecifying  the 
window  in  the  text  of  each  template. 


An  IDA  inside  a  subsystem  may  provide  operations  lo  satisfy  the  common  requirements  of  several 
port  bearing  activities  or  subsystems  The  diagram  may  be  simplified  in  such  cases  by  merging  the 
paths  together  This  is  illustrated  in  the  diagram  below 
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The  module  which  defines  the  operations,  required  by  a  port,  provided  by  a  window,  and  hence 
defines  the  interactions  along  a  path  is  the  access  Interface.  This  is  a  specification.  In  the 
mandatory  subset  of  the  Mascot  definition,  the  contents  of  an  access  Interface  are  procedure 
headings.  These  provide  sufficient  information  for  interactions  to  be  invoked  by  an  active  component. 
For  each  procedure  heading  in  the  Interface,  a  corresponding  complete  procedure,  known  as  an 
access  procedure,  appears  in  the  template  for  the  passive  component.  The  syntactic  structure  is 
shown  in  outline  below. 


It  consists  of  a  name  part ,  which  establishes  the  class  of  the  module  and  gives  the  specification  a 
name: 


acc  ,int  name  part 


and  a  specification  part  which  takes  the  following  form: 


The  specification  part  optionally  begins  with  a  ’  WITH  section'  which  expresses  the  dependency  of 
this  module  on  other  modules.  The  simplest  Interfaces  (those  which  refer  only  to  data-types  which 
are  basic  to  the  implementation  language)  contain  no  dependencies,  and  the  specification  part  then 
reduces  to  a  set  of  procedure  headings. 
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The  following  is  an  example  of  a  simple  access  Interface  with  no  external  dependencies. 


ACCESS  INTERFACE  send_1  ; 

PROCEDURE  secure  ; 

PROCEDURE  release  ; 

PROCEDURE  transmit  (  i  :  integer )  ; 

END 

The  '  WITH  section'  of  an  access  Interface  contains  a  list  of  references  to  definition 
specifications  and  so  implements  the  mechanism,  referred  to  above,  by  which  definitions  may  be 
shared  by  several  Interfaces 


WITH  flow  data,  table  , 

The  syntactic  structure  of  a  definition,  which  has  no  graphical  representation,  is  as  follows: 
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The  content  of  a  definition  module  is  limited  to  the  definitions  of  symbolic  constants  and  data  types.  It 
is  beyond  the  scope  of  this  Handbook  to  define  precisely  how  types  are  defined  in  a  definition 
module  and  how  these  types  can  be  used  by  other  modules,  since  this  impinges  on  the  syntax  and 
semantics  of  the  implementation  language  selected.  However,  a  particular  implementation  may: 

(1)  insist  that  any  data-type  used  in  the  Interface  will  be  defined  in  a  definition 
module  of  the  same  name  and  named  in  the  '  WITH  section',  or 

(2)  allow  any  data-type  used  in  the  Interface  to  be  undefined,  on  the  assumption  that  it 
will  be  defined  in  one  of  the  definition  modules  named  in  the  '  WITH  section',  or 

(3)  insist  that  any  data-type  used  in  the  Interface  is  already  defined  in  one  of  the 
definition  modules  named  in  the  '  WITH  section'. 

The  following  examples  illustrate  the  use  of  definitions. 


DEFINITION  colour  , 

TYPE 

colour  =  (red,  green,  yellow,  blue)  ; 

END 

DEFINITION  palette  , 

WITH  colour  , 

CONST 
max  =  10  : 

TYPE 

palette  =  ARRAYfl  ..  max]  OF  colour  ; 

END 

ACCESS  INTERFACE  spectrum  ; 

WITH  palette  , 

PROCEDURE  paint(  shade_card  :  palette  )  ; 

END 


Pens 

The  textual  representation  of  a  port  is  shown,  in  syntactic  form,  below: 


BfllL  sp.ec 

0 


REQUIRES 


acc  int  ref  list 
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The  following  are  examples  of  individual  port  specifications 

REQUIRES  g  get, 

pa,  pb  put. 

where  get  and  put  are  the  names  of  access  Interfaces  defining  two  sets  of  operations  required  in 
this  template  The  formal  port  names  g  pa  and  pb  are  used  for  two  main  purposes  First  they  are 
used,  m  network  modules,  to  express  the  connectivity  of  the  components  Second,  in  a  simple 
module,  they  must  be  used  to  identify  a  particular  port  procedure  The  syntax  of  such  a  reference  is  as 
shown  below 


portjdentifier 


KM 


procedurejdentifier 


where  the  procedure  identifier  after  the  is  specified  in  'he  access  interface  which  defines  the  type 
of  the  selected  port 


Windows 

The  textual  representation  of  a  window  is  shown,  in  syntactic  form,  below 


window  spec 


where  the  form  of  the  list  is  the  same  as  that  shown  above  for  port  specifications 


The  following  are  examples  of  window  specifications 

PROVIDES  g  get  . 

pa.  pb  put  . 
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where  get  and  put  are  the  names  of  access  Interfaces  defining  two  sets  ot  operations  which  this 
module  makes  available  to  the  outside  world.  The  implication  of  these  specifications  is  that  the  module 
implements,  directly  or  indirectly,  the  procedure  headings  in  the  bodies  of  the  access  Interfaces  get 
and  put 

The  formal  window  names  g,  pa  and  pb  are  used  for  two  main  purposes.  First,  they  are  employed,  in 
network  modules,  to  express  the  connectivity  of  the  components.  Thus  a  construction  such  as 


ida  identifier 


window  identifier 


is  used  to  refer  to  a  specific  window  of  a  specific  IDA  component. 
Second,  the  following  construction: 


window  identifier 


procedurejdentifier 


(similar  to  that  already  discussed  in  connection  with  ports)  may  be  used  in  establishing  the 
correspondence  between  access  procedures  and  the  procedures  made  available  at  specific 
windows  References  of  this  type  are  to  be  found  in  the  access  equivalence  lists  described  in 
Section  2  6 
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.4  SYSTEMS  AND  SUBSYSTEMS 

Description 

Mascot  supports  progressive  development  of  a  design,  from  outline  to  completion,  with  checks 
performed  for  logical  consistency  at  each  stage.  The  detailed  arrangements  whereby  this  is  achieved  are 
described  in  Section  3  1.  In  this  section  we  examine  the  design  feature  which  makes  hierarchical, 
top-down  design  expression  possible  in  Mascot,  the  concept  of  systems  and  subsystems.  These 
design  elements  perform  a  constructional  role.  Known  formally  as  networks,  they  define,  for  part 
(subsystem)  or  all  (system)  of  a  Mascot  application,  the  components  which  are  to  be  created  and  how 
they  are  to  be  connected  together 

In  choosing  the  order  of  presentation  of  topics  in  this  Definition,  it  has  been  judged  desirable  that  the 
decompositional  aspects  of  Mascot  should  be  treated  before  embarking  on  detailed  descriptions  of  the 
various  forms  of  system  component  Inevitably,  then,  this  section  is  concerned  with  the  construction  of 
systems  from  building  blocks  whose  nature  remains  to  be  fully  revealed  This  should  present  no 
insuperable  difficulties  provided  that  the  general  principles  covered  in  Section  2  1  have  been 
understood 

In  its  initial  stages,  a  Mascot  design  may  consist  simply  of  a  set  of  subsystems  representing  the  principal 
functional  or  geographical  units  of  the  application.  Since  subsystems  may  possess  ports  and 
windows,  they  can  be  interconnected  by  paths  which,  through  their  associated  access  Interfaces, 
define  the  nature  of  the  interactions  that  are  to  take  place  Subsequently,  the  details  of  the 
subsystems  are  added  in  the  form  of  templates  for  networks  of  activities,  IDAs  and  servers 
together  with  other,  lower  level,  subsystems.  It  is  this  last  feature,  the  ability  to  include  subsystems 
within  subsystems  to  any  depth,  which  facilitates  an  hierarchical  form  of  design  expression  As  a  design 
entity  a  subsystem  may  play  the  role  either  of  a  processing  or  a  communication  element  or  of  a  mixture 
of  the  two. 

As  will  be  seen  below,  the  graphical  representation  of  a  subsystem  would  lead  one  to  suppose,  on  the 
basis  of  a  familiarity  with  the  rest  of  the  Mascot  graphical  conventions,  that  it  necessarily  incorporated  one 
or  more  independently  scheduled  threads  of  execution.  However  exceptions  can  arise.  Since  the 
existence  of  a  subsystem  is  established  before  its  internal  design  is  carried  out.  there  is  always  the 
logical  possibility  that  subsequent  decomposition  will  show  that  no  component  activities  or 
subsystems  are  required.  This  is  an  allowable  form  and,  where  it  arises,  the  subsystem  is  functionally 
identical  to  either  a  composite  IDA  or  a  composite  server  (both  of  which  are  the  subject  of  later 
sections) 
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A  system  is  a  network  which  encompasses  the  whole  of  the  application.  Explicitly  or  implicitly, 
constitutes  a  complete  description  of  the  software.  It  is  the  highest  or  outermost  level  of  the  hierarchic 
design  expression.  Consequently  it  differs  from  a  subsystem  only  in  having,  by  definition,  no  extern 
dependencies  other  than  those  which  may  be  satisfied  during  system  building  (see  later  Section  2.8)  / 
communication  with  hardware  or  software  objects  in  its  external  environment  is  implicit.  In  the  remainder 
this  section,  attention  will  be  directed  largely  to  subsystems  of  which  the  system  will  be  treated  as 
special  case 

Graphical  Representation 

A  subsystem  is  represented  in  a  Mascot  network  diagram  by  a  closed  curve  with  rounded  corners.  A 
it  is  by  nature  a  composite  entity,  it  is  drawn  as  a  thick  or  double  line  or  in  such  other  distinctive  form  a 
may  have  been  adopted  as  a  suitable  convention.  The  shape  is  usually  that  of  rounded  rectangli 
External  dependencies  are  shown  by  lines  which  pass  through  the  boundary  of  the  symbol  and  whei 
these  represent  paths  they  terminate  in  either  a  port  or  a  window  symbol. 

Tne  diagram  below  shows  a  subsystem  as  it  might  appear  in  the  early  stages  of  design.  Its  extern 
dependencies  are  determined  but  not  its  internal  structure. 


get 


This  particular  example  possesses  two  ports  and  a  window  and  its  purpose  is  to  process  two  input  dat 
streams  to  produce  a  single  output  stream.  The  next  diagram  displays  the  internal  structure  of  th 

template  subsys_5 
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Two  activities,  a  and  at,  created  from  templates  act  ana  act_l  respectively,  are  connected  to  the 
two  externally  visible  ports  which  evidently  receive  the  two  input  streams  Each  activity  is  connected 
via  a  separate  path  to  a  separate  window  of  the  IDA  m  These  two  internal  paths  are  represented  by 
distinct  access  Interfaces,  trans  and  trans_1  Finally  it  is  IDA  m  created  from  the  template 
merge,  which  provides  the  externally  accessible  window. 

subsys_5  is  a  simple  example  but  is  relatively  general  in  possessing  both  ports  and  windows. 
subsys_6  below,  on  the  other  hand,  has  only  ports  and  therefore  externally  resembles  an  activity. 


Conversely,  subsys_7  externally  resembles  a  pure  communication  element 
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As  a  final  graphical  example,  triplex,  to  seasoned  Mascot  users  an  old  friend  in  a  new  guise,  illustrates  a 
subsystem  with  embedded  subsystems  in  its  structure. 


The  thick  lines  of  the  symbols  dup_1  and  dup__2  reveal  these  components  to  be  of  a  composite 
nature.  They  are  subsystems  and,  furthermore,  they  are  both  instances  of  the  same  template, 
duplicate  Notice  that  the  design  would  have  to  be  expanded  to  at  least  another  level  down  to  reveal 
the  components  which  actually  provide  the  facilities,  defined  in  access  interface  get,  provided  at 
the  three  subsystem  windows  triplex  itself  possesses  a  port,  In,  and  three  windows,  outl. 
out2  and  out3  all  of  type  get 

Mascot  2  users  may  be  inclined  to  wonder  at  the  complication  of  the  well  known  elementary  example  of 
trlpllcated_expanslon  Under  what  circumstances  would  it  be  necessary  to  use  a  subsystem  rather 
than  an  eminently  simple  activity  to  duplicate  a  data  stream  without  transformation  (for  such  is  the 
traditional  version  of  this  example)?  The  explanation  arises  from  the  applicability,  mentioned  in  the 
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Introduction,  of  Mascot  3  to  very  large  distributed  computing  systems.  If  each  of  the  three  data  streams 
associated  with  the  two  instances  of  subsystem  template  duplicate  fall  under  the  jurisdiction  ot 
different  processors  with  private  and  shared  memory  units,  something  considerably  more  complicated 
than  a  two-statement  activity  may  be  needed. 


IfMtif-lliH'U^ilHlMlI 


The  syntactic  structure  of  a  Mascot  subsystem  template  is  shown,  in  outline,  below. 


subsys_name_part 


subsys_spec_part 


networkJmp_part 


The  name  part  establishes  the  class  of  the  module  and  gives  the  template  a  name. 


identifier 


For  example. 

SUBSYSTEM  subsys_5  ; 

The  specification  part  specifies  the  network  dependencies  Its  syntax,  in  the  mandatory  subset,  is 
defined  in  the  diagram  below 


window_spec 


port_spec 


The  form  of  port  and  window  specifications  is  defined  in  the  preceding  section  of  the  Handbook.  For 

subsystem  subsys_5  the  specification  part  is 
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PROVIDES  g4  :  get ; 

REQUIRES  p4  get  ; 

c4  :  com  ; 

An  important  point  to  understand  is  that  the  subsystem  template  contains  no  algorithmic  coding.  It 
merely  defines  the  nodes  and  interconnections  of  a  network.  As  explained  above,  the  modules  which 
represent  its  component  parts,  the  nodes,  are  activities,  IDAs  and  servers  together  with  other 
subsystems.  The  interconnections  are  paths  whose  types  are  defined  by  access  Interfaces.  All 
the  information  needed  to  create  the  components  and  connect  them  together  is  provided  in  the 
module's  Implementation  part.  Its  syntactic  structure  is  shown  below. 


It  begins  with  a  USES  section  which  lists  all  the  templates  needed  for  the  components  of  the 
subsystem.  This  list  may  not  include  a  system  template. 

USES  act,  act_1 ,  merge  ;  {  subsys_5  } 

USES  act_2,  act_3,  chan  ;  {  subsys_6 } 

USES  act_4,  ch,  ch_1  ;  {  subsys_7  } 

USES  exp,  copy,  duplicate,  dictionary  ;  ( triplex  } 

Next  comes  the  component  part  in  which  components  derived  from  the  templates  mentioned  in 
the  USES  section  are  specified. 
component  part 
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There  are,  including  the  two  special  varieties  of  IDA,  six  different  classes  of  component  which  can  be 
included  in  a  subsystem. 


Each  component  is  individually  introduced  by  the  appropriate  language  word  :  ACTIVITY,  IDA, 
CHANNEL,  POOL,  SERVER  or  SUBSYSTEM  and  given  a  name  These  names  are  the 
component  names  that,  in  the  graphical  form,  appear  just  outside  the  corresponding  symbols.  The 
template  reference  which  follows  is  the  name  of  the  template  from  which  the  component  is  to  be 
created.  The  component  class  must  be  the  same  as  the  class  to  which  this  template  belongs. 
Where  there  are  ports,  their  connections  must  be  specified  in  the  following  manner: 


This  is  equivalent  to  a  set  of  actual  parameters  in  the  call  of  a  procedure.  To  continue  the  analogy,  the 
ports  specified  in  the  component  templates  correspond  to  the  formal  parameters.  For  every  port  a 
connection  to  a  matching  window  must  be  established,  either  explicitly  or  by  way  of  another  matching 
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port  on  the  boundary  ot  the  enclosing  template. 


port  window  connect 


Thus  the  interconnection  information  consists  of  a  list  of  identifies  expressed  in  the  'formal  =  actual’ 
convention  Where  the  connection  is  an  internal  one,  the  reference  is  to  an  explicit  internal  window. 
Window  names  must  be  qualified  with  the  name  of  the  component  which  provides  them.  Where  the 
connection  is  an  external  one,  the  'actual  parameter’  is  the  formal  name  of  a  port  on  the  boundary  of  the 

subsystem 

Returning  to  the  subsystem  diagram  for  triplex,  it  is  now  possible  to  derive  the  equivalent  textual 
representation  Its  specification  part  is: 

PROVIDES  outl,  out2,  out3  :  get  ; 

REQUIRES  in  :  get  ; 

and  its  components  are 


POOL  look_up  :  dictionary  ; 

SUBSYSTEM  dup_1  :  duplicate  ; 

SUBSYSTEM  dup_2  :  duplicate  ; 

ACTIVITY  e  :  exp  (  g  =  in, 

ep  =  dup_1.p, 
dp  =  look_up.dw); 

ACTIVITY  c  :  copy  (  g  =  dup_1  .g2, 
cp  =  dup_2.p)  ; 


The  port  specifications  of  the  exp  template  are: 

REQUIRES  g  :  get;  ep  :  put  ,  dp  diet  ; 
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and  that  of  the  template  copy  : 


REQUIRES  g  :  get  ;  cp  :  put  ; 

Notice  that  the  port  to  port  connection  is  represented  by  specifying  In  as  the  connection 
corresponding  to  the  port  g  of  activity  e.  That  is,  instead  of  specifying  an  explicit  window  to  satisfy 
this  requirement,  the  port  of  the  activity  is  identified  with  that  of  the  enclosing  subsystem.  A 
corresponding  window  would  have  to  be  provided  within  any  system  or  subsystem  having  a  triplex 
component. 

The  next  aspect  of  subsystem  templates  to  be  discussed  is  the  representation  of  (boundary) 
window  to  (internal)  window  and  (boundary)  window  to  (boundary)  port  connections.  These  are 
dealt  with  by  means  of  an  equivalence  list  (not  to  be  confused  with  the  access  equivalence  list 
used  in  IDA  templates  to  establish  a  correspondence  between  windows  and  access 
procedures). 


Using  subsys_7  as  an  example  : 

p3  =  c.pw  ; 
g3  =  cl.gwl 


In  the  case  of  triplex,  all  the  externally  visible  windows  are  provided -by  subsystems 

outl  =  dup_1  gl  ; 
out2  =  dup_2.g1  ; 
out3  =  dup_2.g2 


To  illustrate  to  boundary  window  to  boundary  port  connection,  a  path  straight  through  subsys_8 
(below'  would  be  defined  thus: 


g  =  P 
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V 


The  following  examples  summarise  the  features  of  subsystem  modules. 


SUBSYSTEM  subsys__5  ;  {  name  part } 

{  specification  dependencies } 
PROVIDES  g4:get;  { window  specification } 

REQUIRES  p4  get  ; 

c4  com  ;  { port  specifications } 

{  Implementation  dependencies  ) 

USES  act,  act_1 ,  merge  ;  (  component  templates  } 

{  components  and  Interconnections  } 
IDA  m  :  merge  ; 

ACTIVITY  a  :  act  (  p  =  p4, 

tp  =  m.tw )  ; 

ACTIVITY  al  :  acM  (  c  =  c4, 

tpl  =  m.twl  )  ; 

{  equivalence  list  j 
g4  =  m.g 
END 


SUBSYSTEM  subsys_6  ,  {  name  part  J 

{  specification  dependencies  J 

{  PROVIDES .  no  window  specifications  ) 

REQUIRES  g2  get  ; 

p2  :  put ;  { port  specifications } 

{  Implementation  dependencies  } 

USES  act_2,  act_3,  chan  ;  {  component  templates  } 

{  components  and  Interconnections  ) 
CHANNEL  c  :  chan  ; 

ACTIVITY  al  act_2  (  gp  =  g2, 

PP  =  C.pw )  ; 

ACTIVITY  a2  :  act_3  (  gpl  =  c.gw, 

PP1  =  P2 )  ; 

(  no  equivalence  list } 

END  . 
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SUBSYSTEM  subsys._7  ;  {  name  part ) 

{  specification  dependencies } 

PROVIDES  p3  put  ; 

g3  :  get ;  { window  specifications  } 

{  REQUIRES .  no  port  specifications  } 

{  Implementation  dependencies  } 

USES  act_4,  ch,  ch_1  ;  (  component  templates  } 

{  components  and  Interconnections  } 

CHANNEL  c  :  ch  ; 

CHANNEL  cl  :  ch_1; 

ACTIVITY  a  :  act_4  (  gp  =  c  gw, 

pp  =  cl.pwt  ); 

{  equivalence  list  } 
p3  =  C.pw  ; 
g3  =  cl  gwl 
END 

SUBSYSTEM  triplex  ;  {  name  part } 

{  specification  dependencies } 

PROVIDES  outl,  out2,  out3  :  get  ;  {  window  specifications  } 
REQUIRES  in  :  get ,  !  port  specification } 

{  Implementation  dependencies  } 

USES  exp,  dictionary, 

copy,  duplicate  ;  {  component  templates  } 

(  components  and  Interconnections  ) 

POOL  look  up  :  dictionary  ; 

SUBSYSTEM  dup_1  :  duplicate  , 

SUBSYSTEM  dup_2  :  duplicate  ; 

ACTIVITY  e  :  exp(  g  =  in, 

ep  =  dup_l  p, 

dp  =  lookjjp.dw)  ; 

ACTIVITY  c  :  copy(  g  =  dup_l.g2, 
cp=  dup_2.p); 

{  equivalence  list  } 
outl  =  dup_1  gl  ; 
out2  =  dup_2.gl  ; 
out3  =  dup_2.g2 
END  . 


Finally  in  this  section  we  turn  to  systems.  As  explained  earlier,  a  system  is  simply  a  subsystem  with 
no  ports  or  windows  In  the  graphical  form  no  paths  cross  the  boundary  of  a  system  symbol  which  is 
otherwise  identical  to  that  representing  a  subsystem.  The  system  diagram  below  uses  three  of  the 
subsystems  which  have  been  discussed  above. 
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The  syntax  which  describes  the  textual  form  of  a  system  is  a  modification  of  that  for  a  subsystem  to 
take  account  of  the  absence  of  ports  and  windows  and  the  fact  that  no  equivalence  list  is 
required 
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component_part 


*> 


The  list  of  templates  in  the  USES  section  may  not  include  a  template  for  a  system. 


Using  system  total  as  a  basis,  the  following  example  summarises  the  features  of  a  system  module 


SYSTEM  total ;  {  name  part ) 

{  implementation  dependencies } 

USES  a,  subsys_7,  triplex,  subsys_6.  drive_1 ,  drive_2,  drive_3  ; 

{ component  templates  } 

{  components  and  interconnections  } 

SERVER  il  :  drive_1  ; 

SERVER  i2  drive_2  ; 

SERVER  i3  :  drive_3  ; 

SUBSYSTEM  ssl  :  subsys_7  ; 

SUBSYSTEM  ss2  :  triplex  (  in  =  ssl  g3  )  ; 

SUBSYSTEM  ss3  :  subsys_6  (  g2  =  ss2.out1. 

p2  =  if  p ); 

SUBSYSTEM  ss4  ;  subsys_6  (  g2  =  ss2.out2, 

P2  =  i2p); 

SUBSYSTEM  ss5  :  subsys_6  (  g2  =  ss2.out3. 

p2  =  i3.p ); 

ACTIVITY  al  :  a  (  p  =  ssl  p3  ); 

END 
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2.5  ACTIVITIES 


Description 


Mascot  application  software  is  conceived  in  terms  of  a  set  of  independent  threads  of  execution  which  is 
mapped  onto  a  hardware  configuration  containing  an  arbitrary  number  of  processors.  There  are  normally 
fewer  processors  than  there  are  computational  threads  and  it  is  the  responsibility  of  the  scheduling 
function  of  the  Mascot  Context  software,  acting  either  pre-emptively  or  in  co-operation  with  the 
application  software,  to  allocate  the  available  processing  power  appropriately.  The  unit  of  scheduling  for 
this  purpose,  an  individual  process,  is  known  as  an  activity. 

Thus  activities  are  the  fundamental  processing  elements  in  a  Mascot  application.  Conceptually,  all 
activities  are  executed  in  parallel  In  practice,  when  any  two  communicating  activities  are  considered, 
there  may  be  literal  parallelism  resulting  from  their  being  mapped  onto  distinct  processors  or 
pseudo-parallelism  if  they  share  the  same  processor.  In  the  latter  case,  depending  on  the  mode  of 
scheduling  being  employed,  the  synchronisation  problems  arising  from  their  use  of  common  data  may  be 
identical  with  those  met  with  in  tme  parallelism 

It  is  a  principle  of  the  Mascot  philosophy  that  the  mechanisms  necessary  to  safeguard  the  integrity  of  data 
communicated  between  activities  should  be  embodied  not  in  the  activities  themselves  but  in  a 
separate  communication  element  This  is  the  intercommunication  data  area  or  IDA  which  is  discussed  in 
detail  in  a  separate  section  It  encapsulates  the  shared  data  area  and  normally  provides  access  to  it 
through  a  procedural  interface  Mascot  activities  therefore  never  communicate  with  each  other  directly 
but  always  through  the  intermediary  of  an  IDA  In  such  transactions  the  activity  is  the  active  participant 
which  invokes  the  operations  specified  in  an  access  Interface  and  provided  by  the  passive  IDA. 

A  consequence  of  this  approach  is  that  an  activity's  influence  on  the  remainder  of  the  application 
software  is  restricted  to  its  interactions  with  the  IDAs  to  which  it  is  connected.  In  particular,  it  is 
uninfluenced  by  the  existence  of  any  other  component  Its  part  in  the  overall  application  is  limited  to 
using,  processing  and  transmitting  the  data  which  flows  to  it  along  the  paths  of  the  network. 

A  Mascot  system  consists  of  a  network  of  activities  and  IDAs.  Each  of  the  activities  present  has 
been  created  from  an  activity  template  In  some  cases  several  of  the  activities  may  have  been 
created  from  the  same  template  Since  each  template  is  a  distinct  design  entity,  developed 
independently,  it  is  important  that  there  are  means  of  exercising  control  over  the  formation  of  a  network. 
The  validity  of  the  connections  must  be  capable  of  being  checked  during  the  construction  process.  The 
formal  arrangements  whereby  a  Mascot  database  records  the  status  or  degree  of  validation  of  each 
module  is  described  in  Section  3  1 
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The  validation  is  carried  out  in  terms  of  access  Interfaces.  An  activity  template  establishes  a 
network  connection  point  by  specifying  a  port.  Each  port  implies  a  connection  to  a  path  of  a  particular 
type  whose  associated  access  Interface  specifies  a  set  of  data  transfer  or  other  operations  The 
coding  necessary  to  implement  these  operations  is  provided  by  an  IDA  possessing  a  window  of 
matching  type  Valid  activity  to  IDA  connections  are  ones  for  which  this  type  checking  proves 
successful 

Graphical  Representation 

An  activity  is  represented  in  a  Mascot  network  diagram  by  a  closed  curve  with  rounded  corners  and 
drawn  with  a  thin  line  Normally,  in  accordance  with  historical  convention,  the  curve  is  a  circle.  External 
network  dependencies  are  shown  by  lines  which  pass  through  the  boundary  of  the  symbol  and 
terminate.  |ust  inside  the  activity  boundary,  in  the  port  symbol 

The  diagram  below  shows  an  activity  template  The  name  of  the  template,  and  of  the  module 
which  represents  it,  is  act  temp  and  this  identifier  is  placed  inside  the  activity  symbol.  As  a  general 
rule  the  name  of  an  activity  should  clearly  reflect  its  function  The  activity  possesses  two  ports,  gat'd 
p  and,  as  the  labels  on  the  two  connected  paths  indicate,  the  external  requirements  which  they 
represent  are  specified  by  access  Interfaces  get  and  put.  respectively 


An  activity  component,  as  opposed  to  an  activity  template,  would  be  represented  as  part  of  a 
network  In  this  case  the  symbol  would  represent  a  particular  component  created  from  a  template 
and  would  be  given  a  name  distinct  from  that  of  the  template  itself.  This  name  is  placed  outside  the 
activity  symbol  Examples  are  to  be  found  in  Section  2  4 

Textual  Representation 

In  the  mandatory  subset  of  the  Mascot  definition,  an  activity  module  takes  the  syntactic  form  shown,  in 
outline,  below. 
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The  name  part  estate;  n  me  class  of  the  module  and  gives  the  template  a  name 

act  name  png 


For  example 


ACTiV'Tv  tvt  temp 


the  specification  pa::  sr eoties  the  network  dependencies.  Its  syntax  is  defined  in  the  diagram 

below 


T, EQfJtnES  p  put  g  .  get 


Finally  the  implementation  pan  defines,  explicitly  or  implicitly,  the  coding  of  this  parallel  thread  of 
execution  Its  synt.i«  si  ..*n  m  Pascal  style  below 
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In  its  simplest  form  it  consists  solely  of  a  block  representing  a  set  of  private  declarations  and  a  sequence 
of  program  statements.  The  program  part  may  define  procedures,  variables  and  constants  etc  which 
are  local  to  the  activity. 

Definitions  of  globally  used  data-types  and  symbolic  constants  are  normally  specified  in  definition 
modules  (described  in  Section  2.3).  They  are  made  available  for  use  in  an  activity  module  through 
the  WITH  section  of  its  Implementation  part  This  simply  lists  the  names  of  the  relevant 

specifications. 

WITH  dataflowtypes,  real_constants  ; 

The  following  outline  example  summarises  the  features  of  activity  templates  described  above 


ACTIVITY  act  temp  ;  (  name  part } 

{  specification  dependencies  ) 

REQUIRES  p  :  put  ; 

g  :  get ;  {  port  specifications  } 

{  Implementation  dependencies  ) 

WITH  dataflowjypes,  real_constants  .  {  global  definitions  ) 

{ local  declarations  } 

{  activity  coding  with  Initial  entry  point } 


END  . 
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2.6  INTERCOMMUNICATION  DATA  AREAS  flDAsl 


Description 


Any  scheme  lor  the  organisation  of  co-operating  parallel  processes  must  include  mechanisms  for  the 
control  of  data  intercommunication.  Where  these  mechanisms  are  imposed,  globally,  by  a  run-time 
system  they  may  often  present  themselves  as  a  constraint  on  the  software  design  process.  The  Mascot 
philosophy  is  to  provide  the  designer  with  the  means  to  create  precisely  the  communication  facilities  that 
are  lequired  between  any  two  activities  in  the  system.  Previous  sections  of  this  Definition  have 
described  how  the  external  network  dependencies  of  an  activity  are  expressed  in  terms  of  the 
procedure  specifications  which  constitute  the  body  of  an  access  interface.  These  procedures,  which 
perform  the  necessary  data  transfers,  are  implemented  in  a  Mascot  design  element  called  an 
;nh-\,ommunication  data  area  or.  more  shortly,  an  IDA  Wherever  information  is  transmitted  between 
activities  r  !-  communicated  through  an  intervening  IDA,  wherever  common  information  is  shared  by 
activities  'i  ,s  stored  in  an  IDA  Thus,  in  general,  IDAs  encapsulate  both  the  shared  data  and  the 
ur'iom  designed  access  mechanisms  necessary  to  safeguard  the  integrity  of  information  being  held  in  or 
juk-d  through  the  IDA 


A  IDA  :s  a  passive  element  The  code  which  it  contains  is  never  scheduled  for  execution  in  its  own  right 
'•■'r  ,  pendent  threads  of  execution  which  form  the  run-time  manifestation  of  activities  simply  pass 
to  •  SDA  todrng  at  points  where  intercommunication  is  taking  place  Several  such  threads  may 
■  f„).ur.eousiy  b  ■  active  or  temporarily  suspended,  within  an  IDA  which  thus  encapsulates  the  critical 
it.:  •.<;  wN.'*  activities  require  concurrent  access  to  the  same  data  structure  When  these 
-.'I-.  unices  ansa  they  may  involve  more  than  one  activity  utilising  the  same  access  mechanism  and 
there  ere  actively  using  the  same  section  of  IDA  code,  or  alternatively  several  different  access 
o  mumsms  may  o-e  operating  concurrently  on  the  same  items  ol  data  The  Mascot  method,  while  leaving 
u,..'  software  designer  t irmly  in  control  ot  the  means  of  solving  the  system's  concurrency  problems 
touts  the  location  of  the  coded  solutions  to  this  one  type  of  component 

A*.  IDA  then.-tore  is  an  encapsulated  data  type  whose  detailed  physical  representation  is  hidden  from  its 
.sers  and  whose  component  values  may  be  manipulated  indirectly  through  a  procedural  interlace  It  fulfils 
two  principal  purposes  m  j  Mascot  network  By  providing  mutual  exclusion  wherever  necessary  between 
activities  competing  tor  the  use  of  a  common  resource,  it  safeguards  the  integrity  of  data  By  providing 
aoss  stimulation  between  co-operating  activities,  it  maintains  the  propogation  of  data  in  the  network 


'  nr  lugh  experience  with  earlier  versions  of  Mascot,  two  simple  classes  of  IDA  have  been  found  to  be 
particularly  useful  The  first  of  these  provides  for  uni  directional  transmission  of  data  trom  one  or  more 
producer  activities  to  one  or  more  consumers  It  is  known  as  a  channel  and  is  characterised  by  a 
destructive  read  operation  and  a  non  destructive  write  As  a  consequence  it  can  become  empty  of  data 
and  as  its  capacity  is  finite,  it  can  also  become  full  The  olher  specially  useful  type  ot  IDA  is  known  as  a 
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pool.  In  this  case  it  is  the  write  operation  which  is  destructive  and  the  read  non  destructive  A  pool 
therefore  a  suitable  kind  of  IDA  to  represent  a  table  or  dictionary  which  activities  periodically  consult 
update.  Many  of  the  simpler  Mascot  networks  can  be  built  satisfactorily  from  activities  channels  ;<•  ■■ 
pools.  The  graphical  forms  of  such  networks  are  normally  referred  to  as  ACP  (Activity  Chance'  l  w; 
diagrams. 

In  general,  active  and  passive  components,  activities  and  IDAs,  alternate  along  the  paths  ol  a  Masco' 
network.  Certainly  adjacent  activities  never  occur.  However,  it  is  sometimes  necessary  for  data  to  r.< 
projected  directly  from  one  IDA  to  another.  Typically  this  requirement  might  arise  where  the  two  IDAs  am 
to  be  accommodated  in  separate  storage  units  addressable  by  separate  processors  Mascot  caters 
this  contingency  by  allowing  IDAs  to  possess  ports  as  well  as  windows  Thus  an  IDA  may  use  acc.  • 
mechanisms  as  well  as  providing  them  and  so  may  be  connected,  by  a  path,  to  another  IDA 


Graphical  Representation 


An  IDA.  in  its  most  general  form,  is  represented  in  a  Mascot  network  diagram  by  a  reclame  nr  ■  ■ 

The  square  corners  of  the  symbol  indicate  the  passive  nature  ot  the  component;!  ropmt  •. 
Throughout  the  Mascot  graphical  notation,  an  exclusively  square  cornered  symbolic  outline  cerbC  •:  - 
decomposition,  to  any  depth,  will  not  reveal  an  active  element  A  rounded  corner,  on  tiu;  other  ’  .v  . 
affirms  the  probability,  but  not  the  certainty,  of  one  or  more  independently  scheduled  t<vva.;s 
execution  being  involved 

External  network  dependencies  are  denoted  by  lines  which  pass  through  the  boundary  the  Vr-  * 
These  lines  are  terminated,  within  the  boundary,  by  a  window  symbol  The  diagram  below  shews  a-  in  A 

template 


The  name  of  the  template  is  lda_temp  and  this  identifier  is  placed  inside  the  rectangu'.  /  ID  '  • 

As  a  general  rule  the  name  of  the  template  should  clearly  reflect  its  function  The  IDA  pos.  -  os 
windows,  p  and  g,  represented  by  the  filled  rectangular  symbols  with  which  two  of  the  oxter:  .i:  , 
connecting  paths  terminate  The  labels  on  these  paths  show  that  the  procedures  provided  by  the  IDA 
at  the  corresponding  windows  are  specified  in  the  access  interfaces,  put  and  get  respectively 


2.6  IDAs 


2  -  51 


Mascot  Version 


A  third  path,  labelled  transmit,  is  shown  crossing  the  bottom  boundary  ot  the  symbol  and  this 
terminates  in  the  port,  t  The  procedures  specified  in  the  corresponding  access  Interface,  transmit 
may  be  used  by  the  IDA  coding  in  order  to  project  information  directly  to  or  from  another  IDA  1  his  mode 
of  data  transfer  takes  place  only  when  a  thread  of  execution  passes  through  the  IDA 

An  IDA  component,  as  opposed  to  an  IDA  template,  would  be  represented  as  pari  of  a  network  in 
this  case  the  symbol  would  represent  a  particular  component  created  Irom  a  template  and  would  be 
given  a  name  distinct  from  that  of  the  template  itself.  This  name  is  placed  outside  the  IDA  symbol 
Examples  are  to  be  found  in  Section  2.4, 

Two  alternative  graphical  representations  are  available  for  channels  and  pools  (described  earlier)  and 
tnese  are  shown  below 


standard  rectangular  symbol  is  slightly  modified  in  each  case  to  make  it  more  reminiscent  of  the 
cnginai  Mascot  2  channel  and  pool  symbols 

Textual  Representation 

!'  the  mandatory  subset  of  the  Mascot  definition,  an  IDA  module  takes  the  syntactic  form  shown,  in 

outline  below 


r  ida 
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The  name  part  establishes  the  class  of  the  module  and  gives  the  template  a  name  it  also 
distinguishes  between  a  generalised  IDA  and  the  two  special  cases:  channel  and  pool 


ida  name  part 


Examples  are 

IDA  ida  temp  , 
CHANNEL  chan  temp 
POOL  pool  temp, 


The  specification  part 


specifies  the  network  dependencies 


Its  syntax  is  defined  in  the  diagram 


below 


The  form  of  the  window  and  port  specifications  is  defined  in  a  preceding  section  of  this  Handbook 
Notice  that  at  least  one  window  must  be  specified 

PROVIDES  p  put  ; 

g  get 

REQUIRES  t  transmit  ; 


The  Implementation  part  defines,  explicitly  or  implicitly,  all  the  coding  contained  in  the  element  it 
syntactic  structure  is  defined  below 
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in  its  simplest  form  it  consists  solely  of  a  declaration  part..  Program  objects  to  which  external  access  is 
provided,  via  a  window  of  the  IDA,  are  distinguished  from  purely  local  entities  by  the  use  of  the  word 
ACCESS  in  their  declarations.  Ignoring,  for  the  moment,  the  WITH  section  an  elementary  example 
might  begin 

CONST 

bufsize  =  100  : 

VAR 

buffer  ARRAY[1  ..  bufsize]  OF  dataJlow_type  ; 
in  pointer,  out  pointer  :  integer  ; 
mq,  outq  controlq  ; 

ACCESS  PROCEDURE  put  data  (  item  datajlow  type  )  , 

ACCESS  FUNCTION  get_„data  :  datajlowjype  ; 

in  this  IDA  a  data  buffer  is  declared  together  with  a  pair  of  pointers  and  two  control  variables,  Inq  and 
outq  wtiose  significance  in  the  Mascot  method  of  process  synchronisation  is  explained  in  the  relevant 
section  ot  this  Handbook  In  conformity  with  the  principle  of  data  hiding,  all  these  variables  are  entirely 
private  to  the  IDA  The  procedure  declaration  section  must  include  an  implementation  of  every 
procedure  made  externally  available  in  the  IDA's  PROVIDES  list  Thus  if  this  was 

PROVIDES  p  put  .  g  :  get  . 

then,  access  interface  put  might  contain  the  specification 
PROCEDURE  put  data  (  i  data  flow  type  )  , 
and  access  interface  get.  the  specification 

FUNCTION  get_data  data  flow  flow  type  ; 

The  purpose  of  the  window  identifiers,  p  and  g.  will  be  explained  shortly 
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Three  other  special  procedures  may  be  included  in  the  declaration  part  and  identified  by  the  words 
INITIALISATION,  RESET  and  TERMINATION  respectively  Their  execution  is  invoked  by  system 
control  functions  as  described  in  Section  4.6  of  the  Handbook.  Any  other  procedures  declared  here  are 
local  to  the  IDA.  They  can  only  be  executed  as  a  result  of  being  called  from  either  get_data  or 
put_data  .  The  procedures  get^data  and  put_data  themselves  are  of  course  invoked  from 
activities  connected  by  paths  to  the  appropriate  window  They  constitute  the  mechanism  whereby 
access  is  obtained  to  the  hidden  data  buffer 

There  is  a  need  to  establish  the  correspondence  between  the  access  mechanisms  in  an  IDA  and  the 
procedures  which  the  windows  indicate  are  to  be  provided.  This  may  be  achieved  by  identity  of  names 
as  in  the  above  example,  or  alternatively  by  the  optional  access  equivalence  list  shown  in  the 
implementation  part  ot  the  syntax 


access  equivalence  list 


Thus,  there  is  provision  for  equating  each  identifier  in  each  window  with  a  corresponding  identifier 
declared  inside  the  IDA;  this  is  known  as  wmdowto local  equivalence.  In  addition  where,  tor  example 
data  propagation  takes  place  directly  between  two  connected  IDAs  an  identifier  in  a  window  may  be 
equated  to  an  identifier  in  a  port  so  that  it  is  a  second  IDA  which  provides  the  functionality;  this  is  knew 
as  window-to- remote  equivalence  For  the  particular  case  where  all  the  functionality  of  a  window  is  to  .  ■ 
provided  externally  there  is  a  shorthand  form  which  equates  all  the  features  of  the  window  to  those  ot  ,i 
matching  port  in  a  single  access  equivalence  statement;  this  is  known  as  window  to  port  equivalence 

Two  examples  ot  window-to-local  equivalence  are 

p  put  data  =  put  data  , 

g  get  data  =  get  data 


i 
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In  general,  using  this  notation,  the  corresponding  procedure  names  need  not  be  the  same.  Indeed,  like 
the  names  of  corresponding  formal  and  actual  procedure  parameters,  they  may  be  expected  to  be 
different  in  other  than  simple  instances  of  IDAs, 

If  our  example  IDA  possesses  a  port: 

REQUIRES  t  :  put  ; 

it  could  be  equated  with  the  matching  window: 


p  =  t 

implying  that  the  the  access  Interface  procedure  put_data  is  to  be  provided  from  elsewhere 
Alternatively,  an  individual  procedure  in  the  window  may  be  equated  to  a  procedure  in  the  port: 

p  put  data  =  t  put  data 

It  will  be  observed  that,  in  the  above  example,  data-types  are  used  which  are  not  defined  in  the  IDA  This 
will  normally  be  the  case  with  data  types  and  symbolic  constants  which  are  used  in  more  than  one 
module  In  order  to  supply  such  global  definitions,  a  specification  module,  known  as  a  definition 
and  described  in  Section  2.3  of  the  Handbook,  is  provided  for  them.  It  is  the  purpose  of  the  WITH 
section  m  the  Implementation  part  of  fhe  simple  fDA  to  import  such  additional  global  definitions  that 
are  needed  but  which  are  not  inherited  from  an  interface 


WITH  data  type_defs.  control  type_defs  ; 


fhe  following  outline  example  summarises  the  features  of  simple  IDAs  described  above  : 


IDA  idajemp  ;  {  name  part } 

{  specification  dependencies  } 

PROVIDES  p  put  ; 

g  :  get :  {  window  specifications  } 

REQUIRES  t  :  transmit  ;  {  port  specification  } 

{  Implementation  dependencies  } 

WITH  .  ,  {  global  definitions  } 

{  local  declarations  } 

ACCESS  PROCEDURE  .  { to  match  all  procedures  } 

{  specified } 

ACCESS  FUNCTION  .  { in  the  windows  provided  } 

{  access  equivalence  list  } 

END  . 
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2.7  SERVERS 


Description 

A  Mascot  application  interacts  with  its  environment  via  a  set  of  peripheral  devices  attached  to  the 
processor  or  processors  on  which  it  is  running  These  devices  generally  appear  to  the  software  as 
sources,  sinks  or  temporary  repositories  of  data  In  some  cases  however,  they  appear  as  initiators  of 
signals,  acquainting  the  software  with  information  concerning  external  events  The  range  of  processors 
for  which  Mascot  systems  are  likely  to  be  implemented  possess  a  variety  of  different  interrupt  handling 
architectures.  Absolute  standardisation  is  therefore  not  possible  and  this  section  of  the  Definition  is 
intended  to  establish  guidelines  as  to  what  Mascot  facilities  are  provided  to  allow  devices  to  be  handled  in 
a  manner  appropriate  to  the  application. 

In  order  to  enhance  the  portability  and  flexibility  of  a  Mascot  system,  it  is  desirable  that  the  application 
dependent  details,  relating  to  specific  devices  and  to  the  architecture  of  particular  computers  should  be 
localised.  This  requirement  is  met  by  a  Mascot  design  element  called  a  server  which  encapsulates  the 
mechanisms  that  control  and  transfer  data  to  and  from  a  particular  device  Servers  communicate  with 
other  Mascot  components  through  access  Interfaces  which  enable  them  to  be  treated  as  far  as 
possible,  like  IDAs  The  aim  is  to  hide  the  application  dependent  details  in  the  same  way  as  the  physical 
representation  of  shared  data  structures  is  hidden 

The  constituent  parts  of  a  server  vary  according  to  the  characteristics  of  the  device  with  which  it  is 
concerned  and  the  uses  to  be  made  of  this  device  by  the  application  software  The  interactions  it 
provides  will  normally  include  'driver'  mechanisms  to  allow  control  signals  and  or  data  to  be  sent  to  the 
device  When  an  interrupt  occurs,  the  action  of  the  Mascot  scheduling  function  is  overridden  by  hardware 
and  control  is  transferred  to  a  section  of  code  encapsulated  in  the  server  and  known  as  a  handler  it  is 
the  handler  which  transfers  information  between  the.  frequently  volatile,  data  registers  of  the  device 
and  the  internal  data  structures  of  the  server  which  are  accessible  to  the  Mascot  network  via  windows 

Servers  share  many  of  the  attributes  of  IDAs;  they  may  possess  both  windows  and  ports  They  differ 
from  IDAs,  however,  in  being  the  only  Mascot  design  elements  which  may  include  handlers  and  other 
code  which  communicates  directly  with  devices  Where  the  mechanisms  used  lor  device  interaction  are 
not  available  to  the  application  software  but  are  provided  by  low  level  procedures  within  the  environment 
the  use  of  these  procedures  is  restricted  to  code  encapsulated  by  a  server 
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A  template  for  a  server  is  represented  in  a  Mascot  network  diagram  by  a  D-shaped  symbol  as  illustrated 
below 


This  template  is  called  devlserver  and  possesses  two  windows,  got  type  get  and  e  of  type 
enable  arid  a  single  port.  /  of  type  Inlt  The  various  forms  of  connection  are  shown  in  their 
conventional  positions  The  rounded  edge  of  the  server  symbol  faces  towards  the  device,  windows 
are  placed  on  the  opposite,  square  cornered  edge  and  ports  on  one  of  the  sides  of  the  symbol  (top  or 
bottom  of  the  D)  The  orientation  of  the  complete  symbol  may  be  chosen  to  suit  the  layout  of  the 
diagram  The  diagram  also  shows  the  device  controlled  by  the  server.  This  is  represented  here  by  a 
hatched  rectangle  but  a  schematic  sketch  of  the  hardware  would  be  equally  acceptable  The  presence  of 
the  device  symbol  and  its  connection  to  the  server  are  optional. 


Textual 


in  the  mandatory  subset  of  the  Mascot  definition,  a  server  module  takes  the  syntactic  form  shown,  in 
outline,  below 
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F 


server  name  part 


1  SERVER  J-  “ 

The  name  part  identities  the  class  of  the  module  and  gives  the  template  a  name  For  example 
SERVER  devl  server 

The  specification  parr  >s  identical  with  that  of  an  IDA  as  described  in  the  previous  section  of  the 
Definition  Reference  '  "vit  section  shows  that  ports  may  be  included  and  that  at  least  one  window 
must  be  spec  ?  diet:!  the  latter  it  could  convey  no  information  to  the  network  and,  therefore 

perform  no  us--*,, 

The  synt act.c  stu. :!!.•■•  '  v.  :  implementation  part  of  a  server  is  shown  below 


first  an  optional  WITH  section  allows  globally  accessible  data  type  definitions  to  be  imported  from 
definition  specifications  The  explicit  contents  of  the  server  template  are  contained  m  the 
succeed  :':;  declaration  part  This  is  similar  to  that  of  an  IDA  It  shares  with  the  IDA  the  requirement 
that  its  procedure  declarations  include  implementations  (distinguished  by  the  word  ACCESS;  of  the 
procedure  headings  ottered  by  its  one  or  more  windows  Correspondence  between  the  access 
interlace  headings  and  the  infernally  declared  procedures  is  established  as  lor  IDAs.  either  by  name 
identity  or  by  means  of  an  access  equivalence  list  the  form  of  which  is  described  in  the  previous 
section  of  the  Def.mtion  INITIALISATION  RESET  and  TERMINATION  procedures  may  also  be 
included  (see  Section  4  6  of  the  Handbook) 

Unique  to  this  type  of  template,  is  the  abilty  to  declare  handlers.  These  routines  are  distinguished 
from  other  procedures  by  use  of  the  design  language  word  HANDLER  in  place  of  PROCEDURE 
Now  follows  an  outline  example,  based  on  the  earlier  graphical  example,  ol  a  complete  module 
representing  a  server 
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SERVER  devl^server  ;  {  name  part } 

{  specification  dependencies  } 

PROVIDES  g  :  get , 

e  :  enable  ;  { window  specifications  } 

REQUIRES  i :  init ;  {  port  specifications } 

{  Implementation  dependencies  } 

WITH .  {  global  definitions  } 

{  local  declarations  } 

ACCESS  PROCEDURE  .  ;  { including  all  procedures  } 

{  specified } 

ACCESS  FUNCTION  .  {  in  the  windows  provided  } 

HANDLER . ;  {  handler  declaration  } 

{  access  equivalence  list  } 

END  . 
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2.8  TEMPLATE  CONSTANTS 


Description 

This  feature  is  not  part  of  the  mandatory  subset  of  the  Mascot  definition 

Collections  of  objects,  of  any  kind,  although  all  created  from  the  same  template,  may  nevertheless  be 
required  to  behave  differently  from  each  other  in  minor  ways  These  individual  secondary  characteristics 
may  be  bestowed  by  specifying,  in  the  template,  constants  whose  values  are  to  be  supplied  to 
individual  components  of  this  type  Such  constants  constitute  another  form  of  external  dependency 
and  are  known  in  Mascot  as  template  constants 

The  range  of  template  constant  types  is  dependent  on  the  implementation  language,  but  could  be 
expected  to  include  any  of  the  implicit  data  types  of  the  language.  The  use  made  of  these  values  is  again 
dependent  on  the  implementation  language  but  they  could  typically  be  used  for: 
device  addresses  (in  a  server) 

-  interrupt  levels  (in  a  server) 
buffer  sizes  (any  simple  template) 
iteration  control  (any  simple  template) 

This  latter  use  might  tor  instance  govern  the  number  of  terms  in  a  series  to  be  evaluated  and  hence  the 
accuracy  and  computation  time  of  a  result 

Just  as  network  paths  may  be  carried,  via  'port  to  port'  or  window  to  window’  connections,  across 
the  boundaries  of  composite  design  elements,  so  template  constants  may  be  transmitted  in  a 
similar  way  to  individual  components  Indeed  powerful  use  of  the  facility  may  be  made  by  bringing 
template  constant  dependencies  out  to  the  enclosing  system  to  be  supplied  dynamically  during 
system  building  ;see  Section  3  2  of  the  Handbook; 

Template  constants  may  be  specified  either  individually  or  in  the  form  of  arrays  in  any  template 

Graphical  Representation 


A  template  constant  is  distinguished  from  a  communication  path,  in  a  Mascot  network  diagram  by  th. 
absence  of  any  terminating  symbol  (such  as  those  representing  ports  and  windows)  in  . i d e  f\. 
boundary  of  the  template  or  component  to  which  it  belongs  Taking  an  activity  template  as  in 
example 
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i  f-,i‘  template  act  temp  a  possesses  a  template  constant,  of  type  integer,  known  internally  as  m 
:  nosing  act  temp  a  to  be  used  to  generate  a  component  of  a  surrounding  subsystem  whose 
■  intuition  is  to  supply  the  value  of  m  ,  this  would  be  indicated  graphically  as  shown  below: 


vs  •  t  v, mm  snows  that  the  template  constant,  which  is  to  be  known  as  k  in  the  subsystem  is  to  be 
;  .ei;  the  value  10  when  the  subsystem  is  itself  created  Similar  diagrammatic  conventions  apply  to  all 

ther  type:-  of  template 

Textual  Representation 

h  fence  to  the  complete  syntactic  descriptions  (to  be  found  in  Appendix  A;  of  any  of  the  Mascot 
v-mpiates  shows  tnat  template  constants  may  be  specified  at  the  beginning  of  their  specification 
.■■arts  "•  the  case  of  a  subsystem  tor  example,  the  complete  syntactic  structure  of  its  specification 
•'<  'cpcsed  to  that  previously  presented  for  the  mandatory  subset)  is' 
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The  additional  syntactic  structure  is  shown  below: 


temp  const  spec 


CONSTANT 


const_spec_list 


const  spec  list 


Us'ng  the  graphical  example  above  to  illustrate  the  textual  torm,  the  activity  template  would  include 

ACTIVITY  act.  temp.  a  ; 

CONSTANT  m  :  integer  , 

END 

The  enclosing  subsystem  transmits  the  constant  through  the  connection  specification  of  the 
component  derived  from  template  act_temp_a  .  This  is  the  same  notation  as  that  used  to  provide 
port  to  window  and  port  to  port  connections.  The  complete  syntax  for  a  connectionspec  is: 
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s 


port_port_connect 


const  identifier 


This  identifies  a  template  constant  with  either  its  ultimate  value  or  with  another  constant  identifier  at  a 
higher  level.  Thus,  the  subsystem  in  our  example  would  contain: 

SUBSYSTEM  subsys^9  : 

CONSTANT  k  :  integer  . 

ACTIVITY  act  act  temp(  m  =  k; 

p  =  ....  ; 


and  the  system 


SYSTEM  sys  : 

SUBSYSTEM  s  subsys  9  (  k  =  10  : 
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4 


Finally,  an  array  of  template  constants  might  be  specified  as: 

CONSTANT  c  :  ARRAY[1..10]  OF  char  ; 
and  its  values  provided  by  a  construction  similar  to  an  Ada  positional  aggregate: 
c  =  ('a',  'b\  'C,  cf,  'e\  T,  'g',  'h*,  T,  'j1 ) 


Alternatively,  the  array  name  c  may  be  equated  with  that  of  an  assignment  compatible  array  at  a  higher 
level  of  the  design  hierarchy. 
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2.9  LIBRARIES 


Description 

This  feature  is  not  part  of  the  mandatory  subset  of  the  Mascot  definition 

In  Section  2  12  of  the  Handbook  it  will  be  seen  that  facilities  exist  in  Mascot  for  the  sequential 
decomposition  of  activities  The  products  of  decomposition  are  roots  and  subroots  whose 
relationships  to  each  other,  and  to  the  adjacent  parts  of  the  data  flow  network,  are  formally  shown  on  the 
diagram  This  feature  is  limited  to  activities  but  all  simple  templates  are  open  to  procedural 
decomposition  in  term?  c!  libraries  which  may  be  shared  by  any  number  of  templates  A  library, 
which  may  be  instantiated  in  any  composite  module,  consists  of  a  set  of  externally  accessible 
proceduies  encapsulated  with  other  purely  private  declarations.  It  does  not  contain  static  data  and 
const.  ;nnot  be  used  as  an  IDA 

A  Mascot  library  implements  one  or  more  library  Interfaces  specifying  which  of  the  program  objects 
declared  m  a  given  library  may  be  used  by  templates  possessing  a  LIBRARY  statement  which  refers 
to  that  interface  Candidates  for  including  such  a  specification  are  simple  IDAs,  libraries,  simple 
activities  and  'he  simple  components  of  composite  activities  It  is  clear,  therefore,  that 
libraries,  ike  IDAs  must  be  capable  of  supporting  multi-threaded  operation.  However  they  must  not 
allow  it itei action  between  the  threads  and  so  are  not  involved  in  problems  of  process  synchronisation 

Gra ph : c aj  Representation 

Neithei  libraries  no<  library  Interfaces  are  represented  on  Mascot  network  diagrams. 

Textual .  Representation 

Library  interface 

A  library  Interface  specification  has  the  tollowing  outline  syntax 
library  interlace 
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[•Jsl 


lib  int  name 


lib  int  spec  part 


with  section 


proofreadings 


The  optional  WITH  section  allows  global  type  and  symbolic  constant  definitions  to  be  imported  to  the 

library  Interface 


Notice  that  variables  are  not  allowed  in  a  library  interface.  Some  examples  follow: 


LIBRARY  INTERFACE  trig  functions  ; 
FUNCTION  sin  (  x  :  real )  :  real  ; 
FUNCTION  cos  (  x  :  real )  :  real  ; 
FUNCTION  tan  (  x  real )  :  real  ; 

END  . 


DEFINITION  complex 
TYPE 

complex  =  RECORD 

real  joart  real ; 
imaginary  part  :  real 

END  : 

END 

LIBRARY  INTERFACE  complex  1  ; 

WITH  complex  , 

FUNCTION  «dd  (  x ,  y  complex  )  complex  , 
FUNCTION  sub  (  x.  y  :  complex  )  :  complex  ; 

END 


LIBRARY  INTERFACE  complex  .2  , 

WITH  complex  : 

FUNCTION  div  (  x.  y  complex  )  :  complex  , 
FUNCTION  mult  x,  y  :  complex  )  :  complex  ; 

END  . 
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The  outline  syntactic  structure  of  a  library  module  is  shown  below 


library 


library  name  part 


c 


LIBRARY 


identifier 


The  specification  part  permits  the  specification  of  template  constants  and  requires  that  the  library 
interface  tor  which  this  template  describes  an  implementation,  should  be  identified  in  a  GIVES 

section 


ljlr.lv. .spec.., .part 


Where  a  library  is  to  give  more  than  one  interface,  the  interactions  provided  in  the  specifications 
must  be  distinguishable  from  each  other 


It  can  be  seen  from  the  syntax  of  the  Inplementatlon  part ,  given  below,  that  definition  and  library 
dependencies  may  be  included 
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library  imp  part 


A  library  specification  may  appear  in  any  activity,  IDA,  server  or  library  template.  Thus  in  the 
complete  Mascot  definition,  an  activity  Implementation  part  takes  the  form  in  Pascal  style: 


simple  act  imp  part 


The  additional  structure  is  a  list  of  library  interfaces: 


library  spec 


The  remainder  of  the  library  Implementation  part  takes  the  form  of  a  set  of  declarations  which  n 
not,  however,  include  variables  This  reflects  the  fact  that  static  variables  are  not  allowed  in  a  librar, 
some  implementation  languages  this  prohibition  might  be  expressed  in  a  different  manner  ! 1 
procedure  declarations  must  include  all  the  procedures  specified  in  the  given  interfaces 
correspondence  is  by  procedure  name 
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The  following  is  an  example  of  a  library  template. 


LIBRARY  trigjib  ; 

{  specification  dependencies  } 

{  CONSTANT . ;  no  template  constants  } 

GIVES  trigjunctions  ; 

{  Implementation  dependencies  } 

{  WITH . ;  no  definition  dependencies  } 

{  LIBRARY . ;  no  library  dependencies  } 

{  local  declarations  } 

PROCEDURE  ....  ;  { including  all  procedures  specified  } 

FUNCTION  . ;  { in  library  interface  trigjunctions  } 

END 


Finally,  a  library  module  may  be  instantiated  within  any  composite  module  and  then  becomes 
implicitly  available  throughout  all  the  other  components.  Thus  the  full  syntax  for  the  the 
component  class  in  the  Implementation  part  of  a  network  module  (given  in  part  in  Section 

2.4)  is: 


component  class 


Taking  subsystem  subsys_6  (Section  2.4)  as  an  example,  library  trig  lib  could  be  made  available 
to  the  two  activities,  al  and  a2,  and  the  IDA  c  by  extending  the  subsystem  module  as  shown 
below: 
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SUBSYSTEM  subsys_6  ;  {  name  part } 

{  specification  dependencies } 

{  PROVIDES . ;  no  window  specifications  } 

REQUIRES  g2  get ; 

p2  :  put ;  { port  specifications } 

{  Implementation  dependencies  } 

USES  act_2,  act_3,  chan,  trigjib  ;  {  component  templates  } 
{  components  and  Interconnections  } 

LIBRARY  t  .  trigjib; 

CHANNEL  c  :  chan  ; 

ACTIVITY  al  .  act_2  (  gp  =  g2, 

pp  =  c.pw  )  ; 

ACTIVITY  a2  :  act_3  (  gpl  =  c.gw, 
ppl  =  p2  )  ; 

{  no  equivalence  list  } 

END 


The  library  template  name  has  been  added  to  the  USES  statement  and  a  library  component, 
derived  from  this  template,  defined  in  the  module.  An  instance  name  for  the  new  component  is 
included  for  the  sake  of  consistency  but  is  not  used  for  any  practical  purpose. 


Use  of  the  library  Interface,  trlgjunctlons,  implemented  by  trigjib,  would  be  indicated  in  the 
template  act_2  as  follows: 

ACTIVITY  act_2  ;  {  name  part } 

{  specification  dependencies  } 

REQUIRES  gp  get ; 

pp  :  to  ;  {  port  specifications  } 

{ Implementation  dependencies  } 

WITH  .  {  global  definitions  } 

LIBRARY  trigjunctions  ;  {  library  Interfaces  used  } 

{  local  declarations  } 

END 

END 


The  coding  of  the  activity  could  then  call  the  functions  sin,  cos  and  tan 


Libraries  may  also  be  instantiated  in  modules  which  represent  sequentially  composite  design 
entities  rather  than  networks  (see  Section  2.12). 
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2.10  COMPOSITE  IDAs 


Description 

This  feature  is  not  part  of  the  mandatory  subset  of  the  Mascot  definition. 

Often,  where  a  network  of  interconnected  IDAs  occurs  in  a  Mascot  design,  it  takes  the  form  of  a 
composite  component  Such  composite  IDAs  furnish  another  means  of  performing  network 
decomposition  in  Mascot,  supplementing  that  described  in  Section  2  4  A  composite  IDA  consists  of  a 
network  of  internal  IDAs  connected  by  paths  and  thus  utilises  the  facility,  described  in  Section  2  6, 
whereby  IDAs  may  possess  ports 

Graphical  Representation 

Composite  IDAs  are  represented  in  higher  level  network  diagrams  by  symbols  of  the  same  shape  as 
those  used  for  simple  IDAs  Their  possible  external  dependencies,  paths  terminating  in  either 
windows  or  ports,  are  also  represented  in  an  identical  manner.  The  following  diagram  illustrates  a 
template  tor  a  composite  IDA  Its  composite  nature  is  indicated  by  the  use  of  a  fhick  line  for  its 
boundary  Alternatively  a  double  line  would  have  the  same  significance  and  other  conventions,  defined 
for  some  specific  set  of  documents,  would  be  acceptable. 


The  squared  corners  proclaim  that  this  symbol  represents  a  wholly  passive  entity  The  template  is  called 
clda  and  its  external  dependencies  are  embodied  in  windows  p  and  g.  expressing  the  tact  that  it 
provides  procedures  specified  in  access  interfaces  put  and  get. 
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W 


The  internal  structure  of  IDAs  created  from  template  clda  involves  three  components  called  ip  op 
and  ex  Each  of  these  is  a  simple  IDA  and  each  is  denved  from  its  own  template  The  three 
templates  are  called  lp_lda,  opjda  and  exjda,  respectively.  In  the  more  detailed  diagram  it  can  b ; 
seen  from  the  window  to  window  connection  at  the  led  of  the  diagram  that  the  interactions  associated 
with  the  externally  visible  window,  p,  are  provided  by  a  corresponding  window,  named  pp  .  of  the 
internal  IDA,  Ip  In  a  similar  way  window,  gg,  of  the  internal  IDA,  op,  is  echoed  to  the  outside  world  at 
the  right  of  the  diagram. 

The  IDA,  ex,  is  a  purely  private  component  of  this  template  Its  single  window  ev.  provides 
facilities,  defined  by  access  Interface,  vis,  which  are  required  by  both  of  the  other  components 
Here,  then,  is  a  more  complete  example  of  direct  IDA  to  IDA  communication 

Further  levels  of  network  decomposition  are  possible  A  thick  line  boundary  to  any  of  the  componen! 
IDAs  of  a  composite  IDA  would  indicate  this.  Such  an  hierarchical  network  structure  is  illustrated  <n  tf.v 
diagram  below  in  which  it  is  the  component  previously  called  ex  which  has  become  composite  i: 
would  be  necessary  to  expand  the  new  template,  cex  lda,  to  at  least  one  level  down  m  crri-j: 
determine  the  component  which  actually  provides  the  interactions  defined  in  access  interface  vis 
in  this  case 
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Where  the  module  scheme  provides  tor  both  simple  and  composite  forms  of  IDA,  the  syntax  is  as 
follows 


The  specification  part  is  as  for  the  simple  IDA 

it  is  in  the  implementation  part  that  the  distinction  between  simple  and  composite  forms  occurs 


Like  all  ether  composite  Mascot  entities,  the  composite  form  of  an  IDA  contains  no  explicit  coding  It 
merely  defines  the  nodes  and  interconnections  of  a  network.  The  modules  which  represent  its 
component  pads  the  nodes,  are  simple  IDA  templates  or  other  composite  IDA  templates  or  a 
mixture  of  both  The  interconnections  are  paths  represented  by  access  Interlaces. 

The  name  and  specification  parts  are  identical  to  those  of  the  corresponding  simple  form 
Windows  and  ports  are  specified  in  the  normal  way  The  implementation  part  takes  a  similar  form  to 
that  of  a  subsystem 

Thus  the  implementation  part  begins  with  a  USES  section  which  lists  the  simple  and  composite 
IDA  templates  from  which  this  composite  IDA  is  to  be  constructed  Referring  back  to  the  graphical 
representation  of  the  composite  IDA  clda 
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USES  ip_ida,  opjda,  exjda  ; 


Notice  that  references  to  definitions  are  not  allowed  at  this  level;  there  is  no  code  to  make  use  of  their 
contents. 


Next  comes  a  list  of  components  Their  syntactic  form  is  as  described  for  subsystems  earlier  in  the 
Handbook  except  that  the  allowed  component  classes  are  IDA,  CHANNEL,  POOL  and 
LIBRARY.  Finally,  an  equivalence  list  establishes  which  of  the  windows  provided  by  the  internal 
components  satisfies  each  window  of  the  enclosing  template. 


To  complete  this  section,  the  template  diagram,  clda,  is  used  as  the  basis  of  a  summary  of  the  features 
of  the  textual  representation  of  a  composite  IDA. 

IDA  cida  :  {  name  part ) 

{  specification  dependencies  } 

{  CONSTANT  .  ;  no  template  constants  } 

PROVIDES  p  :  put  ; 

g  :  get  ;  { windows } 

{  REQUIRES  .  ;  no  ports  ) 

{  Implementation  dependencies  } 

USES  ipjda,  opjda,  exjda  ;  {  component  templates  ) 

{  components  and  Interconnections  } 

IDA  ex  .  exjda  , 

IDA  ip  :  ipjda  (ei  =  ex.ev)  ; 

IDA  op  :  opjda  (eo  =  ex.ev)  , 

{  equivalence  list  ) 

P  =  ip  PP  ; 

9  =  op.gg 
END 
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2.11  COMPOSITE  SERVERS 

Description 

This  feature  is  not  part  of  the  mandatory  subset  of  the  Mascot  definition. 

A  composite  form  of  server  is  provided  in  Mascot  which  consists  of  a  network  containing  at  least  one 
simple  or  composite  server  and  any  number  of  IDAs.  These  components  communicate  with  each 
other  by  means  of  paths. 

Graphical  Representation 

When  drawn  with  a  thick  line  the  D  symbol  is  to  be  interpreted  as  representing  a  composite  server.  Its 
constituent  network  of  servers  and  IDAs,  drawn  inside  the  symbol,  completes  the  representation  of 

the  composite  template. 


The  template  shown  here,  c_serve_temp,  represents  a  composite  server  with  components 
consisting  of  one  simple  server  and  one  simple  IDA.  The  former,  s  is  of  type  ser  Its  two  windows, 
via  window  to  window  connections,  are  accessible  from  outside  the  template.  Its  single  port  is 
connected  to  a  window  of  the  IDA  component,  d  of  type  detail,  whose  other  window  is  carried  to 
the  outside  world. 


Textual  Representation 

Where  the  module  scheme  provides  for  both  simple  and  composite  forms  of  server  the  syntax  is 
as  follows: 
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server 


The  name  and  specification  parts  of  a  composite  server  are  entirely  similar  to  those  of  the 
corresponding  simple  form.  Windows  and  ports  may  be  specified  in  the  normal  way.  It  is  in  the 
Implementation  part  that  the  two  forms  are  distinguished: 


server  imp  part 


Thus  the  Implementation  part  takes  the  same  form  as  in  the  subsystem  and  composite  IDA  with 
the  components  consisting  of  at  least  one  server  possibly  combined  with  one  or  more  IDAs  (which 
may  be  channels  and  pools)  or  libraries  The  USES  section  presents  a  list  of  all  the  templates 
needed  to  construct  the  network  Then  follows  the  component  part  which  defines  the  network 
components  and  their  interconnections  An  equivalence  list  is  used  to  deal  with  window  to 
window  connections. 

This  section  ends  with  an  outline  example,  based  on  c_serve_temp,  ot  a  complete  composite 
server  template 

SERVER  ser 

PROVIDES  sg  get  ; 

se  :  enable  ; 

REQUIRES  si  :  init  ; 


END 

IDA  detail  ; 

PROVIDES  di  :  init  ; 

dp  :  put  ; 

END 
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SERVER  c_serve_temp  ;  {  name  part } 

{  specification  dependencies  } 

{ CONSTANT . ;  no  template  constants  } 

PROVIDES  g  :  get ; 

e  :  enable  ; 

p :  put ;  { window  specifications } 

REQUIRES .  {no  port  specifications  } 

{ Implementation  specifications  } 
USES  ser,  detail ;  { component  templates } 

{  components  and  Interconnections  } 
IDA  d  :  detail ; 

SERVER  s  :  ser  (si  =  d.di)  ; 

{  equivalence  list  ) 
g  =  s.sg  ; 
e  =  s.se  ; 
p  =  d  dp 
END 
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2.12  COMPOSITE  ACTIVITIES 

Description 

This  feature  is  not  part  of  the  mandatory  subset  of  the  Mascot  definition. 

Activity  templates  have  both  the  simple  and  composite  forms.  The  latter  type  is  not,  of  course, 
concerned  with  network  decomposition  but  represents  the  sequential  decomposition  of  the  detailed 
coding  of  an  activity.  The  principal  product  of  this  sequential  decomposition  is  a  design  element  called  a 
root  which  contains  the  initial  entry  point  of  the  composite  activity.  The  remaining  products  of 
decomposition  consist  of  one  or  more  subroots. 

Communication  between  the  components  of  a  composite  activity  is  expressed  and  controlled  in  a 
manner  analogous  to  that  employed  for  network  interactions.  Corresponding  to  the  path  between  the 
elements  of  a  network  there  is  the  link  between  the  sub-elements  of  a  composite  activity  A 
subelement  link  like  a  path,  possesses  a  type  in  the  form  of  a  specification:  in  this  case  a  subroot 
Interface  which  defines  a  set  of  interactions  that  a  root  or  subroot  is  said  to  need  and  which  is 
correspondingly  given  by  another  subroot.  The  validity  of  root  and  subroot  connections  is  checked 
in  terms  of  the  type  of  the  link,  the  subroot  interface,  exactly  as  network  connections  are  checked 
in  terms  of  access  interfaces 

Further  levels  of  sequential  decomposition  are  available  through  templates  for  composite  subroots 
By  this  means  a  subroot  may  by  decomposed  into  a  set  of  internal  subroots  which  together  perform 
the  same  function  as  a  simple  subroot.  That  is  to  say,  the  ensemble  is  able  to  give  the  interactions 
specified  in  exactly  one  subroot  Interface. 

External  network  connections  may  be  made  from  any  component  of  a  composite  activity  Thus 
ports  may  be  specified  in  a  root  or  in  any  subroot  to  correspond  with  those  specified  in  the  template 
which  describes  the  composite  activity  at  its  outermost  level.  The  nature  of  this  correspondence  is 
discussed  in  more  detail  in  connection  with  the  graphical  and  textual  forms  of  representation. 

Graphical  Representation 

The  graphical  conventions  for  roots  and  subroots,  in  composite  activities,  are  similar  to  those  for 
simple  activities.  They  are  normally  represented  by  circular  symbols  to  which  port  connections  may 
be  made  but  they  also  possess  sub-element  links  to  illustrate  sequential  decomposition.  The  latter 
connections  are  shown  as  thin  lines  broken  by  hollow  arrow  heads  which  indicate  the  direction  of 
procedure  invocation.  The  following  diagram  illustrates  a  template  for  a  composite  activity.  Its 
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composite  nature  is  indicated  by  the  use  of  a  thick  line  for  its  boundary. 


The  rounded  corners  proclaim  that  it  defines  an  active  design  element.  The  template  is  called 
compact  and  its  dependencies  are  embodied  in  ports  g  and  p  expressing  requirements  specified  by 

access  Interfaces  get  and  put. 


The  internal  structure  of  activities  created  from  this  template  involves  four  components,  a  root 
called  r  and  three  subroots  called  sul.  su2  and  su3  The  templates  which  define  these  four 
components  are  called  malna  ,  subla,  sub2a  and  sub3 ,  respectively  Three  subroot 
Interfaces,  sll,  sl2  and  sl3  specify  the  interactions  which  the  three  subroots  make  available  via 
sub-element  links  r  makes  use  of  all  three  sets  of  interactions  while  sul  and  su2  utilise  only  the  sel 
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defined  in  s/3. 


The  manner  in  which  these  internal  components  relate  to  the  template's  external  dependencies  is 
shown  by  the  port  to  port  connections  which  continue  through  the  outer  boundary.  From  these  it  can 
be  seen  that  both  rand  sul  utilise  the  operations  defined  in  access  interface  get  and  that  rand 
su2  use  those  in  access  Interface  put 

Since  roots  and  subroots  contain  sections  of  coding  which  are  all  conceptually  part  of  the  same 
activity,  ports  may  be  established  anywhere  in  the  internal  structure.  This  is  illustrated  in  the  template 
compact_l,  below. 


Further  levels  of  the  sequential  decomposition  of  activities,  in  the  form  of  composite  subroots 
possess  a  similar  graphical  representation.  However,  a  composite  subroot  will  show  a  link  which 
penetrates  its  boundary  and  terminates  on  a  simple  internal  root  component  derived  from  an 
appropriate  subroot  template 
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Subroots  established  at  these  deeper  levels  of  nesting  retain  all  the  usual  properties  inherited  from 
activities.  Thus,  on  the  diagram  below,  two  components  of  the  composite  subroot  possess 
ports 


Before  describing  the  textual  form  of  a  template  for  a  composite  activity  it  is  necessary  first  to 
discuss  the  templates  for  its  component  parts  and  their  interconnections,  namely  roots,  subroots 
and  subroot  Interfaces  The  latter  has  a  structure  similar  to  that  for  an  access  interface 
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The  name  part  employs  the  appropriate  alternative  language  word  to  establish  the  class  of  the 
module. 


sub  int  name  part 


i 


SUBROOT  INTERFACE 


>1 


identifier 


while  the  remainder  of  the  module  is  exactly  as  defined  for  the  access  interface  since  the 
specification  part  is  common  to  these  two  types  of  Mascot  Interface. 

The  following  examples  illustrate  some  of  the  possible  forms  : 

{  subroot  Interface  with  procedure  specifications  } 

SUBROOT  INTERFACE  locprocs  ; 

FUNCTION  lactoriaH  i :  integer ) :  integer ; 

FUNCTION  modulo(  i,  j  :  integer )  :  integer ; 

END  . 

(  subroot  interface  with  definition  dependency  } 

DEFINITION  conventions  ; 

TYPE 

vector  =  RECORD 

x  coord :  real ; 
y_coord  :  real ; 
z_coord  :  real 

END; 

directioncosines  =  RECORD 

cos_alpha  :  real ; 
cos_beta  :  real ; 
cos_gamma :  real 

BD; 

END 

DEFINITION  diagram  ; 

TYPE 

diagram  =  RECORD 


END; 


END 
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SUBROOT  INTERFACE  geometry  ; 

WITH  conventions,  diagram  ; 

PROCEDURE  translate(  d  :  diagram;  v  :  vector )  ; 
PROCEDURE  rotate(  d  :  diagram;  dc  :  direction_cosines  )  ; 

END  . 


A  template  for  a  root  naturally  bears  a  close  resemblance  to  a  template  for  a  simple  activity.  Ports 
and  template  constants  may  appear  in  the  specification  part  ;  definition  and  library 
dependencies  may  be  expressed  in  the  Implementation  part  whose  block  section  also  contains  the 
initial  entry  point  of  the  composite  activity  of  which  it  is  a  component. 


1221 


root  name  part 


[rqot  y 


identifier 


> 


The  specification  part  of  a  root  module  differs  from  that  representing  a  simple  activity  only  in  its 
ability  to  express  dependencies  which  are  satisfied  through  subelement  links.  The  following  diagram 
shows  how  this  feature  is  incorporated. 


root  spec  part 
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There  follows  a  possible  outline  for  the  root  module  in  the  composite  activity  template  compact 
shown  in  graphical  form  earlier. 


ROOT  maina  ;  {  name  part } 

!  specification  dependencies  } 

{  CONSTANT . ;  no  template  constants  } 

REQUIRES  rg  :  get; 

ip :  put ;  { ports } 

NEEDS  si  : sil ; 

s2  :  si2  ; 

s3  :  si3  ;  { outward  subroot  links } 

{  Implementation  dependencies  } 

WITH . ;  { global  definitions } 

{  LIBRARY . ;  no  library  dependencies  } 

{ local  declarations } 

BEGIN 

{  statement  sequence  } 

END 

END 


The  syntax  of  a  subroot  module  differs  from  that  of  a  root  in  ways  which  reflect  the  following  different 
properties  : 

(a)  A  subroot  may  appear  at  either  end  of  a  subelement  link.  That  is,  it  may 

implement  facilities  for  use  by  a  root  or  by  other  subroots  as  well  as  using 
such  facilities 

(b)  A  subroot  may  be  composite. 

(c)  Unlike  a  root,  a  subroot  cannot  be  entered  for  execution  directly.  The 

executable  code  that  it  contains  is  all  encapsulated  in  procedures  which  are 
called  through  a  subroot  Interface.  It  therefore  has  no  outer  block 
statement  sequence. 

Difference  (a)  implies  an  addition  to  the  specification  part,  compared  with  a  root  module,  and  (b 
and  (c)  involve  variations  in  the  Implementation  part  As  elsewhere,  the  outline  syntax  is  presented 
first  with  an  expansion  of  the  name  and  specification  parts 

subroal 
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subroot  name  part 


subroot  spec  part 


The  diagram  describing  the  specification  part  shows  that,  after  optionally  specifying  ports  and 
template  constants,  a  GIVES  section  identifies  the  subroot  Interface  which  is  implemented  by 
this  template  It  should  be  noted  that  there  is  precisely  one  such  interface.  On  the  other  hand,  like  a 
root,  a  subroot  may  utilise  (keyword  NEEDS)  the  services  of  any  number  of  other  subroots  through 
subelement  links 


Turning  now  to  the  implementation  part  ;  a  distinction  has  to  be  made  between  the  simple  and 
composite  forms 


subroot  imp  part 


For  a  simple  subroot  the  Implementation  part  is  similar  to  that  for  a  simple  activity  except  for  the 
omission  of  the  statement  sequence 
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Thus,  global  definitions  and  library  sub-threads  may  be  used  exactly  as  in  simple  activities  and  in 
roots.  In  the  declaration  part,  constants,  types  and  variables,  private  to  the  subroot,  may  be 
defined.  These  are  followed  by  definitions  of  the  procedures  which  are  specified  in  the  subroot 
Interface  mentioned  in  the  GIVES  section,  together  with  any  purely  private  procedures  which  the 
interface  procedures  use. 


It  is  now  possible  to  provide,  in  outline,  the  text  needed  to  represent  templates  for  each  of  the 
components  of  the  composite  activity  illustrated  earlier  as  compact.  But  first  the  interfaces 
must  be  specified  Two  access  Interfaces  are  required  for  external  network  communication  and 
three  subroot  interfaces  for  internal  communication  between  the  root  and  subroot 
components 

DEFINITION  network  data_def  ; 

TYPE 

network_data  = . ; 

END  . 

ACCESS  INTERFACE  put  ; 

WITH  network_data_def  ; 

PROCEDURE  write(  item  :  network_data  )  ; 

END  . 

ACCESS  INTERFACE  get  ; 

WITH  network_data_def  ; 

FUNCTION  read  :  network  data  ; 

END  . 

DEFINITION  subroot_data_def  ; 

TYPE 

subroot_data  = . ; 

END  . 

SUBROOT  INTERFACE  sil  ; 

WITH  network_data_def,  subroot_data_def  ; 

FUNCTION  process_1(  item  :  network_data  )  .  subroot_data  ; 

END  . 
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SUBROOT  INTERFACE  si2  ; 

WITH  network_data_def,  subroot_data_def  ; 

FUNCTION  process_2(  item  :  subroot_data  )  :  network_data  ; 

END  . 

SUBROOT  INTERFACE  si3  ; 

PROCEDURE  calculate(  in  :  integer  ;  VAR  out :  integer )  ; 

END  . 


Templates  for  the  root  and  the  three  subroots  can  now  be  outlined: 


dependencies ) 

no  template  constants } 

{ ports } 


ROOT  maina  ; 

{  specification 

{  CONSTANT . ; 

REQUIRES  rg  get ; 

rp:put ; 

NEEDS  Si  :  sil 
s2  :  si2 

S3  :  si3  ;  {  outward  subroot  links  } 

{  Implementation  dependencies  ) 

WITH  .  {  global  definitions  } 

{  LIBRARY . i  no  library  dependencies  } 

{  local  declarations } 

{  root  coding  with  Initial  entry  point  } 

END 


SUBROOT  subla  ; 


{  specification 
{ CONSTANT 
REQUIRES  gg  get  , 


dependencies  } 

no  template  constants } 
{  ports  } 


GIVES  sil  .  { inward  subroot  link  } 

NEEDS  s  :  si3  :  {  outward  subroot  link  } 

{  Implementation  dependencies  } 

WITH .  {  global  detinitions  } 

{  LIBRARY .  no  library  ddependencies  } 

(  Interface  procedures  } 

FUNCTION  process_1(  i  :  network  data  )  :  subroot_data  ; 


END 


SUBROOT  sub2a  ; 


{  specification 
{  CONSTANT 
REQUIRES  pp  put  ; 


dependencies  } 

;  no  template  constants  } 
{ ports } 


GIVES  si2  ;  { inward  subroot  link  } 

NEEDS  s  :  si3  ;  {  outward  subroot  link  } 

{  implementation  dependencies  } 

WITH .  {  global  definitions  } 

{  LIBRARY . ;  no  library  dependencies  } 

{  Interface  procedures  } 

FUNCTION  process_2(  i  :  subroot_data  )  :  network  data  ; 


END 
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SUBROOT  sub3 

{  specification  dependencies  ) 

{  CONSTANT  no  iemplate  constants  } 

{REQUIRES  :  no  ports  used  } 

GIVES  si3  ;  { inward  subroot  link  ) 

{  NEEDS .  no  outward  subroot  links  } 

{  Implementation  dependencies  } 

WITH .  {  global  definitions  } 

{  LIBRARY  no  library  dependencies  } 

{  Interface  procedures  } 

PROCEDURE  calculate;  in  integer  ;  VAR  out  :  integer ); 


END 

To  see  how  to  express  the  template  for  compact  itself,  it  is  necessary  to  return  to  the  discussion  of 
activities  and,  in  particular,  to  the  composite  form  which  has  yet  to  be  described.  The  name  and 
specification  parts  are  entirely  amniar  to  those  of  the  corresponding  simple  template  Thus,  ports 
may  be  specified  in  the  normal  way  'he  Implementation  part,  however,  as  in  the  case  of  a  root,  takes 
alternative  forms  for  simple  and  composite  activities 


act  imp  part 


It  begins  with  a  USES  section  which  lists  the  root  template  and  the  highest  level  subroot 
templates  from  which  the  activity  i?  to  be  constructed  Referring  back  to  the  graphical  representation 
of  the  composite  activity  compact 

USES  mama  subla.  sub2a  sub3 
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This  indicates  which  templates  are  needed  to  create  the  component  parts  of  the  activity.  Notice  that 
references  to  definitions  are  not  allowed  at  this  level.  The  Implementation  part  contains  no  local 
declarations  or  program  statements.  This  is  a  composite  module  and  its  purpose  is  to  specify  the 
internal  structure  of  the  activity  in  terms  of  root  and  subroot  components,  created  from  the 
templates  mentioned  in  the  USES  section,  and  the  subroot  Interfaces  through  which  they 
communicate. 


act  component  part 


act  component  class 


Every  composite  activity  specifies  a  single  root  component  together  with  any  number  of 
subroots  and  any  libraries  which  are  to  be  made  available  to  the  components.  The  specification  of 
each  component  defines  any  connections  it  possesses  to  ports  of  the  act'vlty  and  any  links  to 
subroots 
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The  general  form  of  trie  conin.-„;i>.u  specification  is  very  similar  to  that  already  encountered  for  a 
subsystem  The  syntax  of  port  to  port  connections  and  template  constant  Identities  have  already 
been  described  in  earlier  sections  of  the  Definition  The  subelement  link  syntax  is  given  below: 


Each  outward  link  of  the  component  '  -w«j  <5>.:‘<ined  it?  equated  with  the  subroot  component  which 
is  to  give  the  required  mmr.icn-  m-. 


The  template  for  the  composite  activity  compact  may  now  be  written 


ACTIVITY  con  mac! 

i  specification  dependencies  j 

{CONSTANT  no  template  constants  ) 

REQUIRES  g  get 

P  m  >  pehfs  j 

{  implementation  dependencies  j 
USES  mama  tub’.-  aobl'a.  sub3  ,  {  component  templates  } 
j  components  and  interconnections  } 
SUBROOT  j  1  subla  C  gg  -  g 

s  -  so  3  j  . 

SUBROOT  SU^  subba  i  pp  =  p. 

s  =  su3  )  : 

SUBROOT  su3  <mb3 
ROOT  r  mama  f  ig  -  g. 

ip  =  p. 
si  =  su l . 
s2  -  su2. 
s.)  -  su3  )  , 

END 
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One  topic  remains  to  be  covered  to  complete  the  syntactic  description  of  activities.  This  is  the 
composite  form  of  the  subroot.  Like  the  composite  activity,  it  differs  from  its  simple  form  only  in 
the  Implementation  part.  Furthermore,  this  differs  from  the  corresponding  part  of  a  composite 
activity  only  in  that  it  cannot  contain  a  component  derived  from  a  root  template.  Instead,  the  root 
component  is  derived  from  a  subroot  template  which  gives  the  appropriate  Interface. 

The  template  diagram,  compsub.  at  the  end  of  the  description  of  graphical  representation  will  now  be 
used  to  illustrate  the  application  of  these  syntax  rules. 


SUBROOT  compsub  ; 

{  specification  dependencies  } 

{  CONSTANT . ;  no  template  constants  } 

{  REQUIRES  .  ;  no  ports  }' 

GIVES  si ;  { inward  subroot  link } 

{  NEEDS . ;  no  outward  subroot  links  } 

{  Implementation  dependencies  } 

USES  sub,  sublc,  sub2c  ;  {  component  templates  } 

{  components  and  Interconnections  } 
SUBROOT  sul  :  sublc  ; 

SUBROOT  su2  :  sub2c  ; 

ROOT  su  :  sub  (  si  =  sul, 
s2  =  su2 ); 

END 
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2.13  ARRAYS  OF  PORTS  AND  WINDOWS 


Description 

This  feature  is  not  part  of  the  mandatory  subset  of  the  Mascot  definition. 

Templates  for  both  the  simple  and  composite  forms  of  IDAs,  activities  and  servers  together 
with  subsystems,  roots  and  both  simple  and  composite  subroots  may  specify  ports  by  means 
of  a  REQUIRES  section  in  their  specification  parts  .  The  identifiers  so  introduced  represent  ports 
which  may  be  referred  to  in  the  code  sections  of  the  simple  templates.  In  some  cases  it  may  be 
required  to  transmit  data  via  each  member  in  turn  of  a  group  of  ports  from  a  program  loop.  It  is  therefore 
valuable  to  be  able  to  specify  such  a  group  as  an  array.  Since  all  or  some  of  the  paths  associated  with  an 
array  of  ports  may  pass  through  the  boundary  of  an  enclosing  composite  design  element  it  is  also 
useful  to  be  able  to  use  arrays  at  that  level. 

Of  the  above  list  of  template  types,  simple  and  composite  IDAs  and  servers  together  with 
subsystems  may  also  specify  windows  by  means  of  a  PROVIDES  section.  These  identifiers  are 
used  in  the  connection  specifications  of  simple  templates  and  the  equivalence  lists  of 
both  forms.  Here  again  it  is  useful  to  have  arrays  in  order  to  express  logical  groupings  of  windows. 

The  complete  definition  of  Mascot  caters  for  both  these  requirements 

Graphical  Representation 

An  array  of  ports  or  windows  may  be  representeds  by  a  single  symbol  or,  alternatively,  each  element 
may  be  shown  individually.  Where  the  elements  are  shown  individually  the  array  index  should  also 
appear 

Textual  Representation 


The  extension  of  the  design  language  syntax  to  accommodate  arrays  of  ports  and  windows  in 
REQUIRES  and  PROVIDES  lists  (see  Section  2  3)  is  shown  below: 
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acc  int  array  descrip 


REQUIRES  p_set  :  ARRAYfl  .  .  5]  OF  put  ; 

where  put  is  an  access  Interface.  This  would  facilitate  coding  such  as: 

FOR  line  :=  1  TO  5  DO 
BEGIN 

p_set[line]  .  send(item[line])  ; 

END 

where  send  is  a  procedure  specified  in  the  access  Interface. 

An  array  of  windows  in  an  IDA,  say,  might  be  specified  as: 

PROVIDES  w_set  ARRAY[1  .  3]  OF  get  ; 


and  utilised  in  an  equivalence  list  as: 

w_set[l]  .  fetch  =  fetchl  ; 
w_set[2]  .  fetch  =  fetch2  ; 
w_set[3] .  fetch  =  fetch  3 


to  designate  three  separate  ACCESS  procedures  for  use  in  connection  with  three  logically  related 

paths. 
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2.14  COMPOSITE  PATHS.  PORTS  AND  WINDOWS 


Description 

This  feature  is  not  part  of  the  mandatory  subset  of  the  Mascot  definition. 

Mascot  allows  a  system  design  to  be  expressed  in  an  hierarchical  form  such  that  components  at  the  top 
level  are  decomposed  into  the  more  detailed  components  at  lower  levels  of  the  hierarchy  It  follows  that 
the  granularity  of  the  interactions  on  a  path  in  network  diagrams,  at  different  levels  in  the  hierarchy,  may 
vary.  The  definition  presented  so  far  has  only  provided  for  one  level  of  granularity  to  be  used  for  paths; 
that  is  the  access  interface's  procedures.  The  composite  path  is  provided,  in  the  full  Mascot 
definition,  to  allow  different  levels  of  granularity  to  be  represented. 

The  basic  concept  is  that  a  composite  path  represents  a  'trunk'  route  between  two  subsystems  of  a 
network  The  module  which  defines  the  type  of  a  composite  path  is  an  access  Interface  which 
itself  comprises  a  set  of  lower  level  access  Interfaces.  A  composite  path  is  treated  exactly  like  a 
simple  path  until  it  needs  to  be  split  into  its  component  parts,  at  which  points,  a  special  form  of  'adaptor' 
is  used:  the  composite  port  or  the  composite  window 

Graphical  Representation 

A  composite  path  is  represented  on  a  Mascot  network  diagram  by  a  thick  line  connecting  a  port  of 

one  component  with  a  window  of  another 


This  is  illustrated  in  the  diagram  above  in  which  the  two  components  are  a  subsystem  s  and  a 
subsystem  d  The  name  of  the  composite  path  which  connects  them  is  cpl  The  template  for 
the  subsystem  dsdmpx,  where  the  decomposition  takes  place,  shows  how  the  composite  window 
dswn  is  represented 
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dsdmpx 


ail 


ail 


cp2 


dswn 


Like  a  simple  window,  the  composite  window  is  drawn  as  a  rectangular  shape.  However  it  is  hollow 
and,  like  all  composite  entities,  it  has  a  thick  outline.  It  can  only  occur  on  the  boundary  of  a  subsystem 
template.  On  the  outside  ol  the  template  to  which  it  belongs  there  is  an  external  connection  labelled 
with  the  name  cpl  of  the  composite  access  Interface  which  describes,  indirectly,  the  interactions 
it  provides  Inside  the  composite  window  symbol  the  individual  component  windows  are  shown  and 
labelled  in  the  normal  way  In  this  case,  two  of  them,  a  and  b  .  are  simple  and  are  connected  via  simple 
paths,  both  of  type  all  to  simple  IDA  components  ql  and  q2  The  third  is  itself  composite 
and  is  connected  via  the  composite  path  cp2  to  a  subsystem  component  pi  It  can  be  seen 
from  this  diagram  how  a  composite  window  acts  as  an  adaptor  to  'demultiplex'  a  composite  path 

The  template  for  subsystem  ss  shows  how  the  composite  port  sspn  is  drawn 
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The  composite  port  sspn  is  shown  as  a  hollow  semi  circle,  with  a  thick  boundary,  inside  which  are  the 
'demultiplexed'  ports  a,  b,  and  c  which  it  makes  visible.  Two  of  these  are  simple  and  are  connected  via 
paths  of  type  all  to  corresponding  ports  of  the  subsystem’s  components  c  is  itself  composite 
and  is  connected  via  the  composite  path  cp2  to  a  port  of  the  component  three  .  The  external 
connection  is  labelled  to  show  that  the  interactions  which  it  requires  are  defined,  indirectly,  by  the 
composite  access  Interface  cpl  .  Since  a  composite  port  connected  to  a  composite  window 
must  be  defined  by  the  same  access  Interface,  not  only  the  types  but  also  the  names  of  the 
constituent  ports  and  windows  must  match  in  order  that  constituent  ports  and  windows  of  the  same 
type  may  be  distinguished  from  each  other. 

The  symbols  used  to  represent  composite  ports  and  windows  may  be  drawn  larger  than  the  normal 
size  so  as  to  be  more  in  proportion  to  the  thickness  of  the  path.  This  is  illustrated  by  the  windowc  and 
the  ports  pi  and  c  in  the  above  diagrams. 

Textual  Representation 

The  module  which  defines  the  operations,  required  by  a  port,  provided  by  a  window,  and  hence 
defines  the  interactions  along  a  path  is  the  access  interface.  This  is  a  specification  which  if 
composite  defines,  indirectly,  the  possible  interactions  by  specifying  the  set  of  access  interfaces, 
simple  or  composite,  of  which  it  is  comprised.  The  complete  syntactic  structure  for  an  access 
interface  shows  how  the  composite  form  is  catered  for: 

access  interface 


acc  int  spec  pari 


simple_acc_int_spec_part 


comp_acc_int_spec  _part 


The  specification  part  of  the  composite  form  has  the  following  structure 
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Taking  the  interface  cpI  from  the  above  graphical  examples: 


ACCESS  INTERFACE  cp  1 ; 

COMPRISES  a.b.ail; 

C  :  cp2; 

END 

ail  it  will  be  recalled  is  a  simple  interface  while  cp2  is  composite. 

A  port  or  window  to  handle  a  composite  path  arises  in  the  normal  way  as  a  reference  in  a  list 
following  the  keywords  REQUIRES  or  PROVIDES.  However  in  order  to  indicate  that  a  composite 
path  is  to  be  decomposed  within  a  composite  template,  the  composite  access  Interface  must 
be  referred  to  in  the  USES  list  of  the  template.  The  syntax  is: 


network  imp  part 


The  manner  of  expressing  the  connections  which  fan  out  from  composite  ports  is  revealed  by  the 
complete  syntax  diagram  for  a  port  to  port  connection  as  it  appears  in  a  connection  specification: 
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comp_port_ref 


port_ref 


Returning  to  the  earlier  graphical  examples,  the  following  is  the  textual  form  of  the  subsystem  ssdmpx 


SUBSYSTEM  ssdmpx; 
REQUIRES  sspn  :  cpI; 


USES  cpI ,  ss2,  ss3,  act; 

SUBSYSTEM  two  :  ss2  (pi  =  sspn.a); 
SUBSYSTEM  three  .  ss3  (pi  =  sspn.c); 
ACTIVITY  al  :  act_5  (  pi  =  sspn.a, 
p2  =  sspn.b); 


END 


At  the  other  end  of  a  composite  path,  connections  fan  out  from  a  composite  window.  These,  being 
window  to  window  connections,  are  defined  in  an  equivalence  list  for  which  the  complete  syntax 
diagram  is: 


equivalence  list 


Thus  the  template  for  the  subsystem  dsdmpx  in  the  graphical  examples  is  expressed  as; 


2.14  Composite  Paths/Ports/Windows  2  -  99 


Mascot  Version  3.1 


SUBSYSTEM  dsdmpx; 
PROVIDES  dswn  :  cpI ; 

USES  cpI,  idap,  idaq; 
IDA  ql  :  idaq; 

IDA  q2  :  idaq; 
SUBSYSTEM  pi  :  ssp; 


dswn. a  =  ql  qa; 
dswn.b  =  q2.qb; 
dswn.c  =  pi  pc; 

END 


and  for  completion  here  is  the  template  for  the  system  which  connects  the  subsystem  and  the 
composite  IDA  together: 

SYSTEM  example; 

USES  dsdmpx,  ssdmpx; 

SUBSYSTEM  d  :  dsdmpx; 

SUBSYSTEM  s  :  ssdmpx  (sspn  =  d  dswn); 

END 
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2.15  DIRECT  DATA  VISIBILITY 


Description 

This  feature  is  not  part  of  the  mandatory  subset  of  the  Mascot  definition 

One  of  the  essential  objectives  of  Mascot  is  to  control  access  to  shared  data  from  concurrently  executing 
activities.  The  responsibility  for  this  control,  and  hence  for  the  integrity  of  the  shared  data,  is  normally 
exercised  solely  by  the  IDA.  In  special  circumstances,  however,  it  may  be  necessary  to  bypass  the 
protection  normally  afforded  by  the  access  procedure  mechanism  and  to  allow  activities  to 
manipulate  IDA  data  directly.  There  are  two  classes  of  problem  which  may  be  solved  by  this  means: 

1 .  The  tirst  problem  concerns  the  location  of  code  and  data  on  multi-processor  configurations.  It  may 
be  necessary  to  locate  shared  data,  that  is  IDA  data  areas,  and  the  code  which  operates  on  them 
in  separate  areas  of  memory.  This  problem  may  also  arise  in  single  processor  configurations  which 
possess  non-homogeneous  memory.  A  possible  solution  is  to  use  a  composite  IDA  and  to 
provide  direct  data  visibility  in  the  Interfaces  between  its  components.  Instances  of  the 
component  IDAs  can  be  placed  in  the  appropriate  memory  locations  during  the  building  of 
the  application  software. 

2  The  second  problem  is  concerned  with  efficiency  of  access  to  data.  There  are  some  occasions 
when  the  overhead  associated  with  the  call  of  an  access  procedure  far  outweighs  the 
processing  time  and  memory  space  required  by  the  access  mechanism  code  itself  If  this  applies 
in  a  path  along  which  data  transfers  occur  at  a  high  frequency,  the  overall  efficiency  may  become 
unacceptably  low  In  such  cases  direct  data  visibility  could  be  used  to  eliminate  the  access 
procedure  calls 

The  advantage  of  solving  problems  like  these  by  means  of  direct  data  visibility  is  that  it  is  easy  to 
implement  and  does  not  imply  great  complexity  in  the  Mascot  building  process.  Furthermore,  where 
activities  are  scheduled  for  execution  in  a  co-operative  manner  {see  Section  4.4) ,  direct  manipulation 
of  IDA  data  need  present  no  threat  to  their  integrity.  Under  a  regime  of  pre-emptive  scheduling  safe 
access  may  be  achievable  by  very  careful  programming 

The  use  of  direct  data  visibility  should  only  be  considered,  however,  where  the  conventional  Mascot 
methods  are  incapable  of  achieving  the  required  results  Where  it  is  adopted  it  should  only  be  used  in  a 
disciplined  manner.  Direct  visibility  involves  extending  the  traditional  sole  responsibility  of  the  IDA,  in 
respect  of  data  integrity  and  propagation,  to  a  group  of  several  components  The  scope  of  this  collective 
responsibility  needs  to  be  be  well  defined  and  should  be  limited  as  far  as  possible  by  the  use  of 
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qualifiers  as  discussed  below 


The  programming  system  in  use  for  a  particular  application  may  provide  an  alternative  approach  to  the 
problems  of  efficiency  and  code  and  data  location  One  of  the  following  techniques,  where  available,  is 
generally  to  be  considered  preferable 

1  An  option  provided  by  a  number  of  modern  compilers  allows  a  procedure  body  to  be  included, 
inline,  in  the  object  code  at  the  point  of  call  and,  subsequently,  optimised.  Where  such  a  facility  is 
available  it  might  be  applied  to  calls  of  an  access  procedure,  hence  achieving  an  improvement 
in  performance  similar  to  that  obtainable  through  direct  visibility.  The  feature  may  also  provide  a 
means  of  appropriately  locating  the  code. 

2  The  problem  of  explicitly  locating  code  and  data  may  sometimes  be  solved  by  means  of  compiler 
segmentation  options.  Many  existing  compilers  provide  facilities  for  splitting  compilation  units  into 
segments  which  may  be  independently  located  in  memory.  In  simple  cases  this  may  involve 
division  into  code  and  data  segments  but,  if  steering  directives  are  embedded  in  the  source  text, 
more  complex  separation  is  possible  Mascot  building  software  could  be  developed  to  exploit 
such  compilation  facilities  For  example,  IDA  code  could  be  placed  in  shared  memory,  it  could  be 
duplicated  in  its  entirety  in  the  private  memory  of  each  processor  which  uses  it,  it  could  be 
segmented  manually  and  segments  duplicated  in  private  memory  as  necessary  or  the 
segmentation  could  be  performed  automatically  so  as  to  minimise  the  duplicated  code.  These 
examples  would  achieve  progressively  greater  efficiency  of  memory  usage  in  return  for 
progressively  greater  complexity  of  the  building  software 

Graphical  Representation 

There  are  no  special  diagrammatic  conventions  associated  with  direct  data  visibility.  The  diagram  below 
shows  a  composite  IDA  in  which  data  in  component  ex  is  made  directly  visible  to  the  other  two 
components  through  the  access  Interface  data  vls  In  this  example,  for  which  modules  are 
outlined  below,  ip  and  op  are  required  to  be  located  in  the  private  memory  areas  of  two  separate 
processors  while  ex  is  to  be  located  in  a  shared  memory  area.  This  arrangement  is  reflected  by  the 
broken  lines  on  the  diagram. 
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Textual  Representati< 


IDA  data  may  be  made  directly  visible  by  specifying  them  in  an  access  Interface  that  appears  in  the 
PROVIDES  list  of  the  module.  Reference  to  Appendix  A  shows  that  the  specification  part  of  a 
simple  access  Interface,  in  its  complete  form,  is 
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Thus  variables  and  read-only  constants  may  appear  in  an  access  interface  together  with  the 
procedure  headings  already  discussed.  It  should  be  emphasised  that  interfaces  contain  specifications 
and  not  declarations  Storage  space  tor  interface  variables  and  read-only  constants,  like  the  coding  for 
Interface  procedures,  must  be  supplied  by  any  component  which  provides  a  window  of  that  type 


Referring  to  the  graphical  example  given  earlier,  here  is  the  module  for  the  composite  IDA 
dp_chan 


IDA  dp_chan; 

PROVIDES  in  in  ch; 

out  out_ch; 

USES  dp  in,  dp  .out,  dp_ex; 
IDA  ex  dp  ex, 

IDA  ip  :  dp  in  (e=ex  e); 

IDA  op  dp  _out  (e=ex.e); 


in  =  ip  in. 
out  =  op  out 

END 


There  are  three  access  interfaces,  one  of  which  is  used  internally  and  involves  direct  data  visibility  It 
could,  for  example,  be  of  the  form 


ACCESS  INTERFACE  data  vis; 

VAR 

max  CONSTANT  integer;  { reading  and  writing  operations  } 
data  integer,  (  are  assumed  to  be  indivisible  } 

END 

The  two  interfaces  provided  by  dp  chan  are  conventional  in  containing  only  procedure 
specifications  They  are  outlined  in  sufficient  detail  for  present  purposes  below: 


ACCESS  INTERFACE  in_ch; 

PROCEDURE  write(  item  :  integer  ); 

END 

ACCESS  INTERFACE  out  ch; 
FUNCTION  read  :  integer; 

END 


For  the  purposes  of  explanation,  the  following  examples  are  expressed  in  a  Pascal  like  notation 
Template  dp_ex  is  given  in  full  Notice  the  use,  in  the  design  representation  language,  of  ACCESS 
VAR  by  analogy  with  ACCESS  PROCEDURE,  max  has  been  rendered  as  a  read-only  constant 
whose  value  is  set  in  the  IDA  template  in  order  to  demonstrate  the  facility  In  practice  it  would  probably 
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be  a  template  constant.  The  equivalence  statements  are  not  strictly  required  as  name  identity  gives 
unambiguous  correspondence. 


IDA  dp_ex; 

PROVIDES  e  :  data_vis; 

ACCESS  VAR 

max  :  CONSTANT  integer  :=  50; 
data  :  integer; 

e.data  =  data; 
e.max  =  max 

END 

Only  those  parts  of  template  dp_!n  which  are  relevant  to  the  present  discussion  are  included  in  the 
module  below.  Access  procedure  write  places  input  values  directly  into  the  internal  store  data  of 
IDA  ex  which  is  located  in  the  shared  memory  region. 


IDA  dp_in; 

PROVIDES  in  :  in_ch; 

REQUIRES  e  :  data_vis; 

ACCESS  PROCEDURE  write  (item  :  integer); 

BEGIN 

e  data  :=  item; 

END 

in  write  =  wnte 

END 


The  template  dp_out  provides  access  function  read  at  its  window  out  This  removes  values 
directly  from  the  store  in  ex 


IDA  dp_out; 

PROVIDES  out  :  out_ch; 

REQUIRES  e  :  data_vis: 

ACCESS  FUNCTION  read  :  integer; 
BEGIN 

read  :=  e.data; 

END. 

out. read  =  read 

END 


Finally,  to  assist  in  maintaining  integrity  when  using  direct  data  visibility,  consideration  should  be  given  to 
the  use  of  the  qualifiers  SINGLE,  READ  ONLY  and  IDA  ONLY  (see  later  section  on  this  topic). 
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The  qualifier  SINGLE,  associated  with  an  IDA  window  specification,  indicates  that  only  a  single  thread  ot 
execution  may  pass  through  this  window.  This  effectively  limits  the  scope  of  any  variables  directly  visible 
at  the  window.  The  READ_ONLY  qualifier  can  be  used  to  ensure  that  externally  visible  variables  are  not 
altered  by  direct  access  via  that  Interface.  The  effect  of  the  IDA_ONLY  qualifier  associated  with  an 
access  interface  is  to  restrict  its  use  to  the  ports  and  windows  of  IDAs  As  a  result,  responsibility  tor 
the  integrity  of  visible  data  is  limited  to  the  components  ot  a  composite  IDA  or  equivalent  network 
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2.16  QUALIFIERS 


Description 

This  feature  is  not  part  of  the  mandatory  subset  of  the  Mascot  definition 

Mascot  provides  a  rich  set  of  facilities  for  representing  the  structure  of  concurrent  software.  The  use  of 
these  facilities  is  constrained  in  various  ways  in  the  interest  of  maintaining  the  consistency  of  the  design 
and  the  integrity  of  the  resultant  software.  Such  constraints,  built  into  the  definition,  apply  generally  to  all 
Mascot  systems.  However,  it  will  sometimes  be  found  desirable  to  introduce  additional,  more  severe 
constraints  which  apply  locally  to  particular  aspects  of  a  design.  The  concept  of  a  qualifier  has  been 
devised  to  meet  this  requirement. 

Examples  ot  Mascot  entities  to  which  qualifiers  may  be  applied  are  ports,  windows.  Interfaces  and 
their  components.  The  effect  produced  by  adding  a  qualifier  might  be  to  impose  or  relax  some  form  of 
constraint  on  network  connectivity,  to  limit  the  operations  which  may  be  applied  to  shared  data,  to  indicate 
(in  the  textual  form  of  representation)  the  direction  of  data  flow,  to  limit  the  use  of  selected  context 
facilities  to  certain  classes  of  template  or  to  influence  the  action  of  the  compilation  system 

It  is  open  to  the  implementors  of  a  Mascot  development  environment  to  provide  support  for  any 
qualifiers  that  are  considered  useful  for  the  expected  applications  For  each  qualifier  that  is 
supported  it  is  required  that  the  following  be  defined: 

-  the  name  of  the  qualifier 

-  the  purpose  of  the  qualifier 

-  where  the  qualifier  may  be  placed  and  how  it  is  represented 

-  the  effect  of  the  qualifier 

-  whether  placing  one  qualifier  requires  the  placement  of  other  similar  or 
complementary  qualifiers  and,  if  so,  what  the  rules  are 

-  any  other  information  thought  to  be  relevant  such  as  whether  violation  of  the 
rules  constitutes  an  error  or  merely  results  in  a  warning 

Some  examples  showing  how  this  information  might  be  presented  ar'e  given  later  in  this  section 

Graphical  Representation 

Qualifiers  do  not  normally  appear  on  Mascot  diagrams 
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As  indicated  above,  the  representation  of  qualifiers  in  modules  is  implementation  dependent  It  is, 
however,  suggested  that  qualified  windows  and  ports  might  take  the  following  form: 

REQUIRES  a,  b/READ_ONLY,  c  :  get; 

PROVIDES  d/SINGLE  :  put; 

where  the  proposed  significance  of  these  qualifiers  is  described  below. 

Examples 

The  sample  qualifiers  given  below  are  those  which  were  suggested  during  the  discussion  of  this 
concept  in  the  course  of  development  of  the  Mascot  3  definition  They  are  divided  into  categories  each 
of  which  is  now  briefly  introduced. 

Connectivity  Constraints 

The  default  connectivity  requirement  for  a  window  is  that  at  least  one  port  must  be  connected,  and 
possibly  several  Use  of  the  qualifiers  in  this  category  has  the  effect  of  adjusting  these  requirements 

Data  Access  Constraints 

The  qualifiers  in  ‘his  category  place  limits  on  access  to  variables  made  directly  visible  via  an  access 
Interface 

Data  Flow  Indicators 

These  qualifiers  are  used  to  indicate  the  direction  of  data  flow  with  respect  to  ports  and  windows 
This  is  information  which,  in  the  mandatory  subset  of  Mascot,  is  expressible  only  in  the  graphical  form  of  a 
design 

Context  Qualifiers 

In  this  category,  the  qualifiers  enable  the  designer  of  a  context  interface  (see  Section  4  1)  to  determine 
which  facilities  are  available  to  which  classes  of  templates  In  some  cases  the  limitation  is  to  particular 

features  of  a  template  class 

Code  Generation  Constraints 

The  qualifier  in  this  category  can  be  used  as  a  possible  alternative  to  making  variables  visible  and 
directly  accessible  via  windows  For  a  more  detailed  discussion  of  this  point  see  Section  2  15  of  the 
Handbook 
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Name 


Place 


SINGLE  window  of  IDA 
or  server 


OPEN  window 
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Description 


Purpose:  to  indicate  that  the  designer  ot  the  IDA  or 
server  has  optimised  the  implementation  in  such  a  way 
that  only  a  single  activity  may  use  that  window 

Effect :  Only  one  activity  port  may  be  connected  to 
this  window 

Additional  Information:  Care  is  needed  in  applying 
this  constraint  where  composite  design  entities  are 
involved  In  particular  the  'singleness'  of  a  window  must 
be  passed  out  to  the  windows  of  the  enclosing 
composite  structure  and  the  number  of  internal  port 
to  port  connections  within  enclosing  subsystems  must 
be  determinable. 

Purpose:  to  indicate  that  a  window  need  not 
necessarily  be  used  in  an  operational  network  It  may 
for  example,  have  been  included  purely  tor  testing 
purposes 

Effect:  The  ENROL  operation  will  not  issue  a  warning 
if  a  window  qualified  as  OPEN  has  no  port  connected  to 
it. 

Additional  Information:  OPEN  windows  may  have 
zero  or  more  connections  Windows  marked  as  both 
OPEN  and  SINGLE  may  have  zero  or  one  port  connected 
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DATA  ACCESS  CONSTRAINTS 


Name  Place  Description 

RE AD_ONLY  port  or  window  Purpose:  to  prevent  the  values  of  variables,  visible 

through  the  window,  being  altered  via  port(s) 
connected  to  the  window 

Effect:  Any  attempt  to  write  data  through  a  READ  ONLY 
port/window  connection  is  identified  as  an  error  when 
the  ENROL  operation  is  applied  to  the  template 
concerned 

Additional  Information:  Where  a  window  is 

qualified  as  READ  ONLY,  it  should  only  be  connected  to  a 
similarly  qualified  port  However,  a  READ  ONLY  port 
may  be  connected  to  any  window  In  order  to  limit  the 
scope  of  cross-checking,  it  may  be  desirable  to  insist 
that  the  READ  ONLY  qualifier  must  appear  on  all  of  the 
ports  and  windows  associated  with  the  path 

IDA  ONLY  window  Purpose:  to  ensure  that  only  ports  ol  IDAs  are 

connected  to  the  qualibed  window 

Effect:  Any  attempt  to  connect  the  port  of  an  activity 
(directly  or  indirectly  via  intervening  subsystem 
boundaries)  to  an  IDA  ONLY  window  will  result  in  an 
error  being  identified  when  the  ENROL  operation  is 
applied  to  the  network  which  contains  such  a  connection 
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Name 


Place 


IN  window  or  port  Purpose:  to  indicate  the  direction  of  data  (low. 

Effect:  The  direction  of  data  flow  may  be  expressed  in 
the  textual  form  of  a  template. 

OUT  window  or  port  Purpose:  to  indicate  the  direction  of  data  flow 

Effect:  The  direction  of  data  flow  may  be  expressed  in 
the  textual  form  of  a  template 

IN  OUT  window  or  port  Purpose:  to  indicate  the  direction  of  data  flow 

Elleci:  The  direction  of  data  flow  may  be  expressed  in 
the  textual  form  of  a  template 
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Name 


Place 


SERVER_ONLY  context  Interface  Purpose:  to  make  qualified  facilities  available  only 

or  component  of  to  servers 

context  Interface 

Effect:  The  use,  in  a  template  which  is  not  a 

server,  of  facilities  qualified  in  this  way  will 

result  in  an  error  being  identified  when  the  ENROL 
operation  is  applied  to  the  template 

H ANDLER_ONLY  context  Interface  Purpose:  to  make  qualified  facilities  available  only 

or  component  of  to  handlers 

context  Interface 

Effect:  The  use,  in  a  template  which  is  not  a 

server,  of  facilities  qualified  in  this  way  will 

result  m  an  error  being  identified  when  the  ENROL 
operation  is  applied  to  the  template  Further 
when  a  server  template  is  enrolled,  only  the  code 
of  any  handlers  inside  it  will  be  allowed  to  use  the 
qualified  facilities  Any  other  uses  will  result  in  an 
error  being  identified  and  cause  the  ENROL 
operation  to  fail 

NOT_HANDLER  context  Interface  Purpose:  to  prohibit  the  use  of  qualified  facilities 

or  component  of  by  handlers 

context  Interface 

Effect :  The  use,  by  a  handler,  ot  facilities 
qualified  in  this  way  will  result  in  an  error  being 
identified  when  the  ENROL  operation  is  applied  to 
the  server  template  which  contains  it 
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IDA  ONLY 


context  Interface 
or  component  of 
context  Interface 


Purpose:  to  make  qualified  facilities  available  only 
to  IDAs 


Effect:  The  use,  by  any  template  which  is  not  an 
IDA,  of  facilities  qualified  in  this  way  will  result  in 
an  error  being  identified  when  the  ENROL  operation 
is  applied  to  the  template. 

ACTIVITY_ONLY  context  Interface  Purpose:  to  make  qualified  facilities  available  only 
or  component  of  to  activities, 

context  Interface 

Effect:  The  use,  by  any  template  which  is  not  an 
activity,  root  or  subroot  will  result  in  an  error 
being  identified  when  the  ENROL  operation  is  applied 
to  the  template. 
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Name 


Place 


INLINE 


port  or  window  Purpose:  to  avoid  the  overhead  involved  in  calling 

access  procedures. 

Effect:  The  compilation  system  is  forced  to  copy 
the  code  of  the  access  procedures,  available  at  a 
qualified  window,  into  the  code  of  a  calling 
template  at  the  point  of  call. 

Additional  Information:  It  would  be  reasonable 
to  provide  a  facility  whereby  the  INLINE  qualifier 
may  be  suppressed  by  means  of  an  IGNOREJNLINE 
option  of  the  BUILD  operation. 
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3.1  STATUS  PROGRESSION 


Introduction 

An  essential  feature  of  a  Mascot  development  environment  is  a  database  capable  of  containing  a 
collection  of  modules  from  which,  together  with  their  derived  products,  application  software  may  be 
created.  As  will  be  demonstrated  later.  Mascot  modules  are  so  defined  as  to  facilitate  the  progressive, 
incremental  elaboration  of  a  design.  In  support  of  this,  the  database  accords  formal  recognition  to  the 
attainment  ot  certain  important  progress  milestones  in  the  development  of  a  module  A  status  value 
associated  with  each  module,  provides  a  measure  of  the  level  of  recognition  attained  and  consequently 
of  the  module's  fitness  for  use  This  value  retlects  not  only  the  progress  made  in  defining  the  module 
itself  but  also  the  state  of  other  modules  to  which  direct  or  indirect  reference  is  made  It  is  assumed 
throughout  this  section  that  status  values  are  maintained  automatically  in  the  database  by  the  Mascot 
development  environment  but  a  manual  recording  procedure  would  also  be  possible  A  development 
environment  may  provide  facilities  to  display  the  module  status  and  possibly  the  inter  module 
dependencies 

As  status  progression  is  closely  associated  with  module  structure  this  is  reviewed  first 

Module  Structure 


Reference  to  the  syntax  diagrams  in  Appendix  A  shows  that  every  Mascot  module  begins  with  a  name 
part  which  defines  its  class  and  gives  the  template  or  specification  it  represents  a  unique  name 
This  is  followed  by  a  specification  part  whose  purpose  is  to  define  that  part  of  the  module  which 
needs  to  be  known  when  it  is  used  by  other  modules  it  establishes  the  external  view  ot  the  module 

For  specifications,  the  specification  part  consists  ot  the  detail  of  the  module  together  with  a 
statement  of  its  dependency  on  other  modules  Such  external  dependencies  occur  only  in  simple 
specifications  and  are  limited  to  the  importation  of  data  type  definitions  from  other  specifications 
They  are  expressed  in  the  form: 

WITH  definition  module  list  ( importation  of  data-types  1 

For  templates,  the  specification  part  consists  of  the  information  required  tor  components  of  that 
type  to  be  included  in  a  composite  template  This  information  includes  several  varieties  ot  external 
dependency  Connections  between  objects  are  expressed  in  their  templates  by  means  ot 
references  to  specifications.  There  are  two  different  kinds  of  connection  which  are  expressed  in  this 
manner  and  in  each  case  the  active  partner  in  the  transaction  is  distinguised  from  the  passive  partner 
First  there  are  those  which  convey  network  interactions  and  are  concerned  with  communication  between 
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f 


Stand-aione  Execution  on  the  Target 

In  the  fourth,  and  final,  configuration  discussed  here  tests  are  carried  out  on  a  tree  standing  target 
utilising  only  the  peripherals  connected  to  that  system  Such  an  approach  has  none  of  the  advantages  ot 


ports  and  windows  These  dependencies  take  the  form: 

REQUIRES  port  list  {  network  Interactions  } 

PROVIDES  window  list 

Second  there  are  those  which  convey  sequential  program  interactions  between  the  individual,  separately 
developed  components  of  a  single  thread  of  execution 

NEEDS  subroot  interface  list  {  sequential  program  Interactions  } 

GIVES  subroot  interface  list 

A  third  form  of  external  dependency,  closely  related  to  the  second  category  above,  occurs  in  the  case  of 
a  template  which  describes  a  collection  of  shared  library  facilities  The  set  of  interactions  which  this 
passive  entity  makes  available  are  expressed  as: 

GIVES  library  interface  list  {  provision  of  library  services  ) 

The  final  possible  element  of  a  specification  part  is  the  template  constant  expressed  as 

CONSTANT  template  constant  list  {  template  constant  } 

Templates  (but  not  specifications)  possess  a  further  section  known  as  the  Implementation  part 
which  detines  the  internal  details  of  the  template.  For  simple  templates  this  defines  the  program 
For  composite  templates  it  defines  the  components  together  with  their  connections  and 
template  constant  values.  Simple  templates  may  import  data  type  definitions  directly  from 
specifications  and  may  make  use  of  facilities  provided  by  library  modules  These  dependencies  are 
expressed  in  the  form 

WITH  definition  module  list  {  Importation  of  data-types  ) 

LIBRARY  library  interface  list  {  use  of  library  services  } 

A  composite  template  depends  on  those  templates  from  which  its  components  are  derived 
These  are  listed 

USES  template  list  (  templates  for  components  } 

Appendix  C  (Summary  of  Keyword  Usage)  lists  all  the  inter  module  dependencies  in  terms  of  the 
representation  language  keywords  used  to  express  them  and  distinguishes  between  those  associated 

with  the  specification  and  implementation  parts  of  a  module 

Status  Values 

The  status  value  of  a  module  directly  reflects  the  state  of  completion  and  validation  of  the  three 
sections  of  its  structure  There  are  thus  three  primary  status  values,  registered.  Introduced  and 
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enrolled,  the  attainment  ot  which  record  the  progressive  successful  validation  of  the  name 

specification  and  implementation  parts  ot  the  module,  respectively.  The  operations, 

computer-assisted  or  manual,  which  establish  these  status  values  are  REGISTER.  INTRODUCE  and 
ENROL 

A  module's  primary  status  value  may  be  qualified  to  reflect  the  status  ot  the  other  modules  which 
belong  to  the  specification  and  Implementation  dependency  trees  of  which  it  is  the  root  Thus,  a 
module  whose  specification  part  is  present  and  correct,  but  which  has  specification  dependencies 
still  at  registered  status  may  be  raised  to  the  status  cf  partially  Introduced  it  qualifies  to  become 

fully  introduced  when  ai'  ;ts  specification  dependencies  have  achieved  this  status 

For  a  composite  template  there  is  a  status  value  ot  partially  enrolled  This  status  can  be 
achieved  when  all  three  sections  of  the  module  are  present  and  correct  and  all  its  specification  and 
implementation  dependencies  are  at  least  partially  Introduced  As  will  be  demonstrated  in  the 
example  below,  the  partially  enrolled  status  conditions  enable  the  system  designer  to  complete  a 
network  design  before  considering  the  interface  and  algorithmic  details  of  the  design. 

The  formal  rules  governing  the  achievement  of  ttiese  status  values  are  summarised  in  a  table  af  the  end 
of  this  section  Their  application  is  illustrated  below  In  trie  example  status  progression  is  shown  as  an 
orderly  increase  m  status  from  registered  to  enrolled  >n  practice,  facilities  must  be  provided  to 
supped  iteration  and  the  consequent  backtracking 

Example  of  Status  Progression 


The  following  example  illustrates  t  ow  a  subsystem  might  be  developed  progressively  The  detailed 
features  of  the  Masco?  development  environment  employ •'•d  m  this  example  are  not  mandatory  to  the 
Mascot  definition  The  subsystem  chosen  tor  illustration  is  the  one  called  subsys  4  in  Section  2  1  cf 
the  Handbook 

The  status  progression  commands  may  be  used  to  control  the  development  of  a  system  by  a  team  of 
people.  We  shall  assume,  as  the  starting  point  tor  our  example,  that  subsystem  subsys_4  has  been 
introduced  and  has  achieved  partially  introduced  status  This  implies  that  the  access 
interfaces  required  ana  provided  by  subsys  4  n.svo  been  registered  and  that  the  only  information 
known  to  the  Mascot  database  about  subsys  4  is  the  following 

SUBSYSTEM  subsys  4 
PROVIDES  gw4  get. 

REQUIRES  rp4  :  rec:  otp4  out  tp4  trans. 
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Our  task  in  the  example  is  to  develop  subsys_4  and  we  shall  define  a  series  of  states  through  which  the 
subsystem  and  its  constituents  must  pass.  These  states  will  be  visible  in  the  Mascot  database  as  a 
result  of  applying  the  status  progression  commands  and  can  thus  be  used  to  control,  record  and 
monitor  progress. 

There  are  three  significant  states  which  arise  during  the  development  of  subsys_4  : 

1  Design  structure  recorded  for  subsys_4 

2  Ready  to  start  implementation  of  templates  from  which  the  components  of 
subsys_4  are  denved. 

3  Completion  of  implementation  of  all  templates  used  by  subsys_4  This  implies  that 
subsys_4  may  be  built. 

State  1  is  reached  when  subsys_4  is  partially  enrolled  This  implies  that  the  templates  for  all  of  its 
components  have  been  Introduced  and  have  achieved  partially  Introduced  status  State  2  is 
reached  when  all  the  simple  templates  tor  the  components  of  subsy_4  have  achieved  fully 
introduced  status  and  state  3  is  reached  when  subsys_4  is  fully  enrolled 

Reaching  State  1 

To  move  from  our  starting  point  to  state  1,  it  is  necessary  to  design  the  internal  structure  of  subsys 4 
This  will  most  probably  be  represented  graphically  first  and,  if  a  graphics  tool  is  available,  could  be 
recorded  directly  in  this  form  In  such  a  circumstance  the  graphics  tool  can,  via  interactions  with  the  user, 
determine  which  additional  modules  need  to  be  registered  and  Introduced  in  order  to  render 
subsys_4  capable  of  achieving  partially  enrolled  status  However  if  a  text  based  design  checking 
tool  is  used,  then  the  next  step  would  be  to  transcribe  the  graphical  representation  of  subsys_4  into  its 
textual  equivalent,  thus 

SUBSYSTEM  subsys  .4; 

PROVIDES  gw4  get; 

REQUIRES  rp4  :  rec;  otp4  out,  tp4  trans; 

USES  pooM,  chan  1,  a  temp  1,  a  temp  2, 

POOL  pi  :  pool  1 , 

CHANNEL  ch  chan  1 , 

ACTIVITY  al  :  ajemp  1  (fp  =  ch  fw,  tp  =  tp4,  pp  =  pi  pw) 

ACTIVITY  a2  a  temp  2  (sp  =  ch  sw,  otp  =  otp4,  rp  =  rp4); 
gw4  =  pi  gw 

END 


From  this  (or  directly  from  the  graphical  representation)  it  can  be  seen  that  in  order  to  enrol  this  design,  it 
is  necessary  to  have  the  four  templates  poo/_  f,  chan  1  a_temp_1  and  a_temp_2  at 
introduced  status  Further,  before  these  templates  can  be  Introduced,  it  is  necessary  to 
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register  them  and  the  access  interlaces  upon  which  they  depend 


■F 

The  specification?  vr  ;t  component  templates  of  subsys_4  are 

' 

ACTIVITY  -i  temp  i. 

REQUiRES  fp  fetch,  tp  trans,  pp  put, 

ACTIVITY  a  temp  2. 

REQUiRES  ?p  send,  otp  out  rp  rec, 

CHANNF  — an  ' 

PROVIDES  send,  fw  fetch. 

POOL  nc~!  ' 

PROViOFS  pw  put.  gw  get. 

It  can  be  seen  teat  11  ■  component  templates  between  them  make  use  of  seven  access 
interfaces  of  which  *  /  ;  •  v.s.bie  at  the  subsystem  template  These  four  will  already  have  been 
registered  to  allow  subsys  4  to  achieve  partially  introduced  status  Therefore  we  need  to 
register  the  thi e-;  acldit  cnal  Interfaces  fetch,  send  and  put  Having  registered  the  four 
templates  and  the  t*  access  interfaces  we  can  introduce  the  templates  and  thereby  submit 
them  lor  formal  checkin':  ::  ’heir  specification  parts 

The  INTRODUCE  opera;  c.  n  fast  checks  that  the  name  parts  of  the  modules  have  not  been  changed 
since  they  we^  reais*’->rnd  a--1  then  checKS  the  specification  part  The  specification  part  must 
itself  be  syntac:  modules  to  which  the  modules  being  introduced  refer 

must  be  at  least  at  leg-s:.-  *ed  status  These  are  the  minimum  requirements  for  the  INTRODUCE 
command  to  sue.  -  •.•■ample  design,  these  minimum  requirements  are  met  Therefore  the 

tour  templates  e  a  '  utiahy  introduced  status 

The  INTRODUCE  cpm,  •  ••  w.i:  also  check  whether  the  preconditions  for  fully  introduced  status  are 
satisfied  At  this  ::  mor*  c'  our  example  these  conditions  are  not  met  because  the 

interfaces  are  not  y-.-t  introduced  Mierefore  the  status  achieved  is  partially  Introduced 

'  It  is  now  possible  to  onto:  :r  design  structure  tor  subsys  4  This  operation  checks  that  the 

specification  part  •  u  ■  "hanged  since  the  module  was  introduced  and  that  the  design 

details  represent  a  com  m.-nt  use  of  the  templates  and  interfaces  involved  As  a  result,  subsys_4 
will  achieve  partially  enrolled  status  State  i  has  new  been  reached 

Reaching  State  2 

In  order  to  reach  state  2.  it  is  necessary  to  have  all  seven  of  the  access  Interfaces  specified  in  detail 
and  for  them  to  be  raised  to  introduced  status  For  the  three  internal  access  interaces  we.  as  the 
nominated  design  authority  (see  section  5  1)  can  proceed  immediately  For  the  four  external  access 

3  -  5 


3.1  Status  Progression 


Mascot  Version  3.1 


interfaces  we  must  liaise  with  other  groups,  who  are  developing  modules  which  also  use  these 
access  interfaces,  and  with  the  nominated  design  authority  for  them 


When  the  internal  details  have  been  agreed,  they  are  recorded  as  the  texts  for  the  access  Interface 
modules  and  any  definition  modules  found  to  be  necessary.  These  details  are  then  submitted  for 
checking  and  entry  into  the  Mascot  database  via  the  INTRODUCE  command.  The  sequence  of 
commands  is  as  follows  REGISTER  all  new  definition  modules;  INTRODUCE  definition  modules; 
INTRODUCE  access  interface  modules 

Assuming  that  these  operations  are  succssful  we  now  have  all  the  access  Interfaces  for  subsys_4 
at  fully  introduced  status  In  order  to  reach  state  2  though,  we  have  to  bring  the  Mascot  database 
up  to  date  by  re  Introducing  the  four  simple  templates  atemp  1  a_temp  2,  poot_1  and 
chan  1  and  finally  re  enrolling  subsys_4 

Reaching  State  3 

The  action  necessary  to  reach  state  3  is  to  provide  the  implementation  details  for  each  of  the  simple 
templates  used  for  the  components  of  subsys_4  This  is  a  programming  task  and  each  module 
can  be  assigned  to  a  different  individual  within  the  team  who  will  then  add  the  details  and  submit  the 
assigned  module  for  enrolment  When  all  the  implementation  details  have  been  provided  and 
checked  to  be  consistent  with  the  fully  Introduced  Interfaces  by  the  ENROL  command,  we  have 
almost  reached  state  3  It  only  remains  to  re  enrol  subsys_4  so  that  it  can  be  related,  in  the  Mascot 
database  to  the  fully  enrolled  simple  templates  Then  subsys  4  can  achieve  fully  enrolled 
status  and  our  task  is  completed 

This  state  formally  constitutes  the  end  of  the  implementation  phase  for  subsys_4  and  signals  the  start 
of  the  testing  phase  for  that  module  Depending  upon  the  testing  strategy  adopted,  there  might  well  be 
other  subsystems  developed  specifically  to  provide  test  harnesses  for  subsys_4  The  development 
of  these  subsystems  and  indeed  the  test  system  required  to  execute  them,  will  follow  similar  lines  to 
that  descnbed  and  use  the  same  commands 

More  Sophisticated  Status  Progression  Commands 


The  status  progression  commands  as  described  here  are  very  simple  and  operate  purely  on  one 
module  at  a  time  although  they  do  require  checks  on  the  status  of  other  modules  It  is  envisaged 
that  more  sophisticated  versions  of  the  INTRODUCE  and  ENROL  commands  could  be  provided  These 
would  be  especially  useful  for  large  systems  particularly  during  the  later  stages  of  integration  and  during 
maintenance 
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In  the  above  example,  the  requirement  to  re-apply  the  INTRODUCE  and  ENROl  commands  a 
details  of  the  design  are  added,  has  been  identified.  Doing  this  manually  is  possible  but  tedious  and  err 
prone.  If  one  of  the  commands  was  omitted  in  error,  this  could  result  in  a  system  being  built  which  tailed 
to  incorporate  some  recent  module  amendments.  The  possibility  of  this  happening  increases  as  the 
size  of  the  system  being  developed  increases.  Therefore,  more  sophisticated  forms  of  the  ENROL  arc 
INTRODUCE  commands  are  defined  which  automatically  seek  out  any  later  versions  of  modules  an-: 
re-apply  the  appropriate  command.  Hence  the  extended  form  of  the  ENROL  command,  possibly  invoked 
as:  ENROL  subsys_4  FULLY,  would  be  interpreted  to  mean  re-enrol  subsys_4  and  any  modules 
which  it  directly  or  indirectly  depends  upon.  Thus  this  leads  to  a  recursive  application  of  the  F ■;n/~ 
command. 

Similarly  the  extended  form  of  the  INTRODUCE  command,  possibly  invoked  as  INTRODUCE  :  Ul  :.v 
would  result  in  recursive  application  of  the  INTRODUCE  command 

A  more  far-reaching  extension  of  the  ENROL  operation  would  allow  re  Introductions  as  welt  a- 
re-enrolment  This  interpretation  may  be  of  value  when  an  Interface  change  is  made  either  late  i-  ti 
development  of  a  system  or  during  the  maintenance  stage  It  provides  a  simple  way  of  bringing  ail  »h“ 
components  of  a  system  to  consistency  with  the  latest  issue  of  the  design 
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Status  Conditions 


Register  I  Registered 


Partially 

Introduced 


Module 

Class 


Full'  All 

Introduced 


Name  part  defined  and  legal 


No  other  module  with  same  name 


Registered  preconditions  satisfied 


Specification  dependencies  Registered 


Speciticatiopn  part  defined  and  legal 


Partially  Introduced  preconditions 
satisfied 

Specification  dependencies 
Fully  Introduced 


Partially  Composite  Partially  Introduced  preconditions 

Enrolled  Templates  satisfied 


Implementation  dependencies  Introduced 


Implementation  part  defined  and  legal 


Fully  Simple  Fully  Introduced  preconditions  satisfied 

Enrolled  Template  Implementation  dependencies  Fully  Introduced 

Implementation  part  defined  and  legal 


Composite  Partially  Enrolled  preconditions 
Templates  satisfied 

Implementation  dependencies  Fully 
Enrolled 
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3.2  SYSTEM  BUILDING 


Introduction 

Building  is  the  term  used  in  the  Mascot  definition  to  describe  the  stage  of  development  which,  starting 
from  a  fully  enrolled  system  template,  produces  a  representation  of  the  network  in  an  executable 
form.  The  process  which  achieves  this  must  take  into  consideration  the  target  configuration  for  which  the 
application  is  to  be  built  the  number  and  type  of  processors  to  be  employed,  the  accessibility  of  memory 
from  each  processor  and  any  special  requirements  for  interfacing  with  devices  In  view  of  this  strong 
target  dependence  and  the  wide  variation  in  the  rangetnfilding  facilities  required  for  different  kinds  of 
application,  the  Mascot  definition  does  not  legislate  on  the  precise  form  which  the  facilities  should  take  or 
on  the  linguistic  support  which  a  Mascot  development  environment  should  provide  in  this  area  Rather,  in 
this  section,  an  attempt  is  made  to  discuss  all  the  factors  which  need  to  be  considered  and  to  recommend 
and  justify  some  preferred  modes  of  working  practice 

Building  Strategies 

The  ultimate  objective  of  building  is  the  construction  of  a  complete  operational  system  However  to 
facilitate  development  particularly  during  the  phase  when  individual  modules  are  being  tested,  it  is 
desirable  to  be  able  to  build  test  systems  which  incorporate  only  part  of  the  final  system  This  can  be 
achieved  by  means  of  a  system  template,  specially  created  for  the  purpose,  which  encapsulates  the 
components  to  be  tested  By  associating  such  test  systems  with  the  test  procedures  and  results,  the 
development  process  can  be  documented  reliably  and  specific  test  exercises  can  be  repeated  should 
the  need  arise 

In  general,  the  object  of  a  test  will  be  a  subsidiary  network  extracted  from  the  complete  system  design 
and  possessing,  in  consequence,  components  with  unconnected  ports  and  windows  A  test 
system  must  therefore  contain  additional  components  to  supply  these  missing  connections  Thus 
the  test  network  may  be  completed  by  means  of  a  dedicated  test  harness  capable  of  supplying  any 
required  input  and  of  recording  and  possibly  checking  any  generated  output  Alternatively,  input  and 
output  could  be  achieved  by  direct  connection  to  external  devices  such  as  a  set  of  files  on  a  host 
computer  in  this  latter  case  the  additiorcdmponents  would  consist  of  servers 

While  it  may  be  acceptable  for  a  small  test  system  to  be  re  built  from  scratch  each  time  amendments  are 
made  to  the  modules  from  which  it  is  derived,  this  is  likely  to  be  a  rafher  laborious  and  time  consuming 
procedure  for  the  large  systems  typical  of  Mascot  applications  and  even  for  the  bigger  test  systems 
employed  during  the  integration  phase  of  development  The  time  taken  to  build  a  system  image  may 
be  reduced  if  a  number  of  the  component  subsystems  have  previously  been  separately  built  The 
context  software  for  a  particular  computer  is  an  obvious  candidate  for  being  made  available  as  a  partially 
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built  image  However  this  approach  is  more  suited  to  some  target  architectures  than  others  It  is,  tor 
example,  particularly  useful  when  building  tor  a  multi  processor  target  where  the  constraints  are 
uniform  But  where  a  memory  mapping  scheme  is  employed  in  the  target,  the  builder  requires  an  overall 
view  ot  the  system  in  order  to  achieve  optimal  results  and  so  building  speed,  in  this  case,  might  have 
to  be  paid  for  in  reduced  efficiency 

During  module  and  integration  testing,  the  same  system  may  be  built  and  re-bullt  many  times  A 
sophisticated  builder  might  detect  that,  between  one  build  operation  and  the  next,  only  a  few 
components  had  changed  and  so  could  save  time  by  re-bullding  as  little  ot  the  system  as  possible  A 
more  limited  builder  might  achieve  the  same  result  with  a  little  assistance  from  the  user 

Linguistic  Support  for  Building 

A  simple  constructional  task  would  be  that  of  building  a  system  for  a  target  consisting  of  a  single 
po,  > 'sser.  of  a  pre  determined  type,  which  has  access  to  sufficient  memory,  all  of  a  uniform  type,  and 
! i.ik.ng  use  of  a  predefined  context  This  could  be  performed  by  a  dedicated  builder  supplied  with  no 
more  data  than  the  identity  of  the  system  template  arid  the  values  ot  any  template  constants  This 
.ntomiation  could  readily  be  accommodated  as  a  set  of  parameters  to  a  BUILD  operation 

BUILD  total  sys.  100.  50 

n  would  be  preferable  however,  even  m  so  simple  a  case,  for  the  data  to  be  presented  in  a  BUILD 
module  to  which  reference  could  be  made  in  initiating  a  BUILD  operation 

BUIt  D  build  mod 

I  his  approach  allows  the  image  to  be  brought  under  configuration  control  so  that  its  regeneration  can  be 
guaranteed  The  range  ot  information  held  in  the  BUILD  module  can  be  extended  tor  use  by  more 
powerful  builders  Where  a  choice  of  contexts  and  processor  types  exist,  tor  example  the  selections 
could  be  specified  in  the  module 

lo  cater  tor  more  complex  targets  more  build  Time  information  must  be  supplied  and  a  decision  must  be 
made  on  whether  to  hold  it  all  in  the  one  data  module  or  to  introduce  others  Suppose,  for  example,  that 
the  builder  supports  target  configurations  with  disjoint  memory  blocks  or  non  homogeneous  memory 
with  differing  speeds  or  modes  of  access  The  size  of  each  memory  block,  its  address  range  and  fs 
properties  must  be  made  available  to  the  builder  together  with  instructions  as  to  where  the  system 
components  are  to  be  located  among  the  various  memory  blocks  Placing  all  this  information  in  a  smgie 
BUILD  module  would  necessitate  its  replication  tor  each  system  built  for  the  same  target 
configuration  and  so  it  might  be  preferable  to  use  a  separate  (TARGET)  module  to  hold  details  ol  the 
target 
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Separation  of  the  build  time  data  in  this  particular  way  would  still  prove  inflexible  where  there  was  a 
requirement  to  build  images  of  the  same  system  for  several  target  configurations  A  possible  solution 
would  be  to  define  the  target  in  software  terms,  such  as  computers  and  memory  regions,  and  to  define 
the  location  constraints  in  terms  of  these  regions  The  target  could  then  be  defined  in  hardware  terms 
such  as  processors  and  memory  blocks,  and  a  correspondence  given  between  the  two  views  For 
maximum  flexibility,  this  information  could  be  divided  between  four  separate  modules  each  belonging  to 
a  distinct  class 

BUILD 

TARGET 

HARDWARE 

SOFTWARE 

The  location  contramts  could  then  be  spread  among  any  number  of  LOCATOR  modules 

It  may  be  that  devices  in  the  target  configuration  are  memory  mapped.  In  such  a  situation,  communication 
with  the  devices  may  be  through  pre  determined  normal  or  special  memory  locations  If  the  necessary 
device  access  information  is  not  embedded  in  the  applications  software  then  it  must  be  supplied  via  the 
builder,  perhaps  by  the  use  of  template  constants 

Further  build-time  data  is  required  to  support  target  configurations  consisting  of  multiple  processors  with 
shared  memory  The  builder  needs  to  know  which  memory  blocks  are  pnvate  to  a  processor  and  which 
can  be  or  which  are  to  be  shared  by  more  than  one  processor  It  may  also  need  an  indication  of  which 
components  are  to  be  allocated  to  each  processor  Where  the  target  processors  are  memory  mapped, 
the  builder  may  require  guidance  as  to  how  each  logical  memory  region  is  mapped  into  a  physical 
memory  block 

In  its  full  generality  then,  the  BUILD  module  might  supply  information  to  the  builder  as  indicated  in  the 
diagram  below 


3  2  System  Building 


3-11 


Mascot  Version  3. 1 


3  2  System  Building 


3-  12 


Mascot  Version  3  1 


3.3  DEVELOPMENT  CONFIGURATIONS 


Introduction 

In  discussing,  in  this  section,  a  range  of  hardware  configurations  appropriate  to  the  development  of 
Mascot  software,  a  distinction  is  made  between  a  host  system,  on  which  the  software  development  takes 
place,  and  the  target  system,  on  which  the  operational  software  is  to  be  executed  The  different 
host-target  combinations  which  are  encountered  in  practice  vary  in  the  degree  of  similarity  which  exists 
between  the  two  systems 

At  one  extreme,  the  host  and  target  may  be  the  same  system  or  the  host  may  combine  a  processor  which 
is  identical  to  that  of  the  target  with  a  subset  of  the  target's  peripherals.  Alternatively,  because 
development  involves  requirements  not  relevant  to  operation  and  because  the  target  peripherals  are 
frequently  of  an  exotic  nature,  the  host  peripherals  may  be  different  to  those  of  the  target  while  the 
processors  are  the  same 

In  other  arrangements,  the  processor  in  the  host  system  may  possess  a  similar  instruction  set  and  number 
representation  to  those  of  the  target  but  may  differ  in  other  respects  such  as  the  manner  in  which 
input  output  is  performed  Sometimes  the  host  and  target  have  a  common  number  representation  while 
their  instruction  sets  differ  Finally,  development  may  take  place  on  a  host  system  whose  processor  has 
nothing  in  common  with  that  of  the  target  at  all. 

Commissioning  Configurations 

The  hardware  configurations  mentioned  above  may  be  employed  to  support  formal  or  informal  execution 
of  the  software  for  the  purpose  of  quality  assurance  and  for  the  diagnosis  and  correction  of  errors  Where 
the  host  and  target  processors  are  identical,  the  validity  ol  testing  depends  only  on  considerations, 
including  those  discussed  below,  which  relate  to  the  run-time  environment  The  four  most  commonly 
encountered  configurations  in  which  host  and  target  systems  differ  are  examined  here  in  orde1  to 
highlight  their  relative  advantages  and  disadvantages 

Native  Code  Execution  on  the  Host 

In  the  first  configuration,  tests  may  be  executed  on  the  host  in  its  own  native  code  Results  may  be 
obtained  rapidly  m  advance  of  the  target  system  becoming  available  for  use  Since,  in  general,  the  host 
can  handle  much  larger  programs  than  the  'arget  it  is  possible  to  test  the  complete  system  in  the 
presence  of  dedicated  test  software  such  as  simulators  and  scenano  generators.  Good  diagnostic 
facilities  can  be  provided  and  all  the  host  peripherals  can  be  made  accessible  to  the  tests  In  many  host 
systems  the  passage  of  system  time  can  be  controlled  though  usually  in  a  relatively  crude  manner 
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Where  the  host  pm-  *‘.sr.v-r  ci.lwTs  from  that  ot  the  target  espjKaat  y  ai  respect  ot  wot  diet  Kjfl1  :r;e 
and  accuracy  o'  t;  e  arithmetic  results  obtained  in  may  net  represent  a  true  incP  atmn  n  the 

performance  t  '  l  .  >  per  ted  on  the  target  Other  aspens  of  the  system  may  not  be  s  its  hi:  t  r,!V 
exercised  t  or  e»amp:e  n.  as  is  common,  only  co-operative  schedule  :)  is  available  on  the  host  the  testing 
ot  mutual  exclus-ci.  .me  .  iocs  stimulation  within  IDAs  is  not  wholly  adequate  Some  parts  r.t  the  code 
suen  as  that  mvi  K -no  n  hamdl.ng  interrupts  usually  have  to  be  omitted  from  testing  altogether 

It  is  important  that  host  and  target  should  be  compatible  in  respect  ot  high  level  program  statements  which 
must,  ot  course  he  ‘••'ompiled  ,or  execution  on  ti  e  target  when  testing  on  the  host  has  been 
completed 


code  compiled  for  the  target  .$  mterpretively  executed  -n  the  t-c r.t 
e  •  i  ,e  that  tor  the  ta  g-  !  th-  re  ;s  no  question  ot  incompatibly  bef.ve*  n 
.  ••  *  ii  tie  accurate  and  renat  -•  .  itm  emulation  is  accurate  i  f-s  ni.;t!  r  d 

a-,  vfn  capabilities  ar.j  •  .  •  peripherals  than  mat  <>  or. ~ s •  • 

..  ’••<.  an  opportunity  to  men  a  *  '  -  >t  !iirt  time  che-  s.nq  ,n  ■  .  •'  f,c  • 

i  ...c  tor  .sample  tor  irithme'  •*  '01  me  use  ct  umruti.ji*; « d  m, i, 

■  ip:;:,  n  c-t  code 

:r>  puis  'p,t  i  •.  mat  execution  time  hem  *  ‘  :  t  f  rms  longer  than  on  :  *.e  ' 1  •  *  - 

•  •  ••  in  this  way  .m  ;  4  •  .  •  ■■.cluJ-  r.  all  real-time  asp.  t  :  •  ’he 

i  '  -  ’■  yl  ••xecut.on  vf'  ■’  .  ,  "  e.  be  useful  to  v«v  .  ‘  :  ' 

•  :  .  •  •  ot  interrupt!  ■  "  ■  :  nt'oiot  the  pissage  ■ 

:  •  :  '  '  ■  ..ug  It  Wi.!  n :  "•  !  •••• 


LmuLVcon  or 1  L! Lie 
m  this  second  aim 
Since  there  cm.- 
nc-r  .no 

^  V  '  C  v,  ^  ■  s, ' r  ••  i  •  » 

e/<'. ,•  In  p.'.d- c.  .. 
v. . i ; •  ■  Ks  can  be  C"  m 
i. ,  ah  ns  and  fca  me 


a  J  c-m  ,  e,r, figuration  involv.- 

it  I  ■  ■ ,  ot  eui  ■  >!.lp.  h  host  wa  a  direct  uni 

D>  I  me,:.  :i  ;  h  .  m  the  need  to  handle  c 

can  be  used  id1  .  .  •  ;  ay  i.cntuin  taalities  su  n  ,■ 

t ina i  opera;,' i  p.-.an-  r-c-v  ded  that  the  targ.  t  . 

peripht‘r.1  ‘ ,  m  be  tested  Qnlv  a  ’ 

source  code  m;  c  t  w,:h  the  host  Potent;  P'. 
previously  d'Scnss-g  .imr  ■ments 


■!  hie-  r. -suits  may  (•••  r  •  .  .)"• 

/.  th  the  he:!  Area  •  •  -  ■  r  r  - , 

w'licti  ee  not  tr  te  ;-  ,.  '*  .'  !'i- 

•  ;  epped  with  a  tu'i  o-t  o'  p--Mh  ;■  ; 

•  squired  and  t‘-. •  ■■■''■ 

‘  ap  ibi'iti-  s  are  as  q'ol  cm  :  tt  - 


1  r,e  disad.a'  ta  ; •  •  .  r  <  <  i  : cat  wh.ie  access  to  -ii' me  >  !;•••;  in  be  provided  it  ,  ••  :  .  ,  ' 

limited  bandwi  !t*>  .  c:  t  is  not  normally  possibi-  !■■  -  ' : i . the  passage  ot  system,  turn:  so  m-  ic 
compensate  t<  ■  ad  •  v  ■■  u  ov  -heads  attnbut.it  'e  ft'.  ;  r,.-..  r  t  test  components  and  ifU.  jink 

tc  the  host 
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Stand-alone  Execution  on  ihe  Target 

In  the  fourth,  and  final,  configuration  discussed  here  tests  are  carried  out  on  a  free  standing  target 
utilising  only  the  peripherals  connected  to  that  system.  Such  an  approach  has  none  of  the  advantages  of 
the  host-linked  arrangement  described  above  but  interference  from  the  link  is  eliminated  It  is  unlikely  that 
the  target  system  provides  a  suitable  environment  for  testing  purposes  and  so  tests  will  be  labonous  and 
time  consuming  to  set  up  and  carry  out.  The  diagnostic  capabilities  are  likely  to  be  very  limited  and  the 
available  peripherals  may  consist  of  no  more  than  a  control  panel  or  a  keyboard  terminal 

Both  methods  in  which  testing  is  performed  on  the  target  encounter  further  complications  when  the 
target  consists  of  multi-processors  which  have  some  shared  memory.  In  this  case,  the  target  system  may 
not,  during  some  phases  of  testing,  be  fully  equipped  with  processors 

The  Software  Environment  for  Test  Execution  on  the  Host 

It  is  normally  desirable,  in  most  development  environments,  to  perform  at  least  some  ot  the  testing  on  a 
host  system  Among  the  many  reasons  for  this  is  lack  of  availability  of  the  target  system  during  the  testing 
phase  of  a  project  This  may  simply  arise  from  the  problem  of  inaccessibility  which  is  due  to  the  target's 
location  at  a  remote  site  and  is  likely  to  be  exacerbated  during  the  maintenance  phase  after  the  system 
has  been  installed  Frequently  however,  the  software  development  team  obtains  access  to  the  target 
system  only  at  a  very  late  stage  ot  production  and  the  system  may  even  then  not  inc'ude  all  the 
specialised  peripherals  Thus  testing  on  a  host  permits  hardware  and  software  development  to  proceed 
in  parallel. 

As  was  made  clear  above,  in  the  discussion  of  test  configurations,  the  target  system  is  likely  to  contain 
few  of  the  diagnostic  tools  which  are  commonly  available  on  a  host  Furthermore,  the  target  may  not  have 
the  penpherals  necessary  to  support  diagnostic  output  Shortage  ot  memory  may  also  be  a  problem  It  will 
rarely  be  possible  to  find  storage  space  lor  test  software  since  all  the  memory  which  can  physica'.y  be 
accommodated  will  in  practice  be  needed  lor  the  application  It  it  were  not.  the  space  would  be  used  for 
other  equipment 

A  further  disadvantage  of  testing  on  the  target  arises  trom  the  length  of  time  taken  to  transfer  code  from 
the  host.  Transfer  may  be  via  a  relatively  slow  link  or  indeed,  may  be  performed  through  the  use  of  a 
magnetic  medium  such  as  a  cassette  A  PROM-based  target  represents  an  extreme  manifestation  of  fins 
problem  involving  as  it  does  the  transfer  of  executable  code  into  PROMs  Difficulty  may  also  be 
encountered  in  transferring  test  data  and  results  to  and  from  the  target  Even  a  direct  link  may  be 
inconveniently  slow  tor  this  purpose  and  may  result  in  excessive  distortion  of  the  real  time  aspects  of 
system  performance 

The  degree  of  compatibility  between  host  and  target  machines  is  the  most  significant  factor  aflecting  the 
usefulness  of  testing  on  the  host  Unless  the  two  processors  are  identical,  the  degree  of  compatibility  is 
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determined  principally  by  the  choice  ot  language  and  compilers  and  by  the  level  ot  support  for 
compatibility  provided  by  the  development  environment.  Where  the  code  ot  at  least  the  majority  ot  the 
application  templates  can  be  executed  on  either  the  host  or  the  target,  with  similar  results,  then  host 
testing  is  likely  to  be  useful.  It  is  quite  feasible  in  this  case  to  test  almost  all  the  software,  up  to  and 
including  the  full  system,  on  the  host.  Those  small  sections  of  program  which  cannot  be  dealt  with  in  this 
way  can  be  tested  after  transfer  to  the  target  and  before  proceeding  to  the  integration  tests.  Some 
iteration  involving  a  return  to  unit  testing  on  the  host  may  be  implied  by  the  detection  of  errors  during 
integration 

Where  host  and  target  are  incompatible  for  all,  or  the  majority,  of  the  application  templates  the 
advantages  of  host  testing  are  lost  since  the  source  code  must  be  edited  before  being  transferred  to  the 
target.  This  presents  a  serious  maintenance  problem  and,  in  addition,  necessitates  the  tests  being 
repeated  on  the  target  system. 
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4.1  CONTEXT  SOFTWARE 


In  any  software  system  it  is  normally  possible  to  distinguish  between  functions  which  are  part  of  a 
particular  application  and  those  which  are  more  properly  to  be  regarded  as  part  of  the  environment  in 
which  the  software  operates  In  Mascot,  this  division  is  reflected  by  the  distinction  between  application 
and  context  software  A  Mascot  development  environment  may  be  expected  to  offer  a  collection  of 
supporting  services  from  whurn  software  designers  can  select  the  set  of  services  needed  for  a  particular 
application.  These  may  include,  for  example,  the  conventional  Mascot  primitive  operations  described  in 
Section  4.2.  The  context  may  also  include  application  specific  items  such  as  procedures  for  controlling 
peripheral  devices  The  general  principle  is  that  a  set  of  procedures,  constants  and  data-types  provided 
in  the  context  for  a  particular  application  is  implicitly  available.  The  set  may  be  subdivided  so  as  to  restrict 
the  use  of  defined  subsets  ct  the  context  facilities  to  specific  classes  of  design  entity  such  as 
servers,  IDAs  or  activities 

The  interfaces  which  the  context  otters  to  the  application  are  described  in  a  form  which  is  consistent 
with  the  Mascot  modularity  scheme  The  term  context  interface  is  used  to  embrace  all  those 
Interfaces  which  are  implicitly  available  to  the  application  software.  Tne  precise  form  in  which  it  is 
expressed  is  implementation  dependent  but  should  be  generally  compatible  with  the  style  of  the 
application  software  modules  Its  components,  however  expressed,  are  a  mixture  of  those  associated 
with  the  library  Interfaces  access  Interfaces  and  definitions  described  elsewhere 

In  a  simple  case,  the  context  Interface  might  be  expressed  as  a  combination  ot  a  library  interface 
and  a  definition  wr- procedures  to  be  called  and  define  data  types  for  use  as 
parameters  Tne  proci'd..-.-*  sin  :  ‘  sat.ons  might  include  control  queue  primitives  together  with  a 
peripheral  I'brar, 

D  E  p !  N !  T 1 0  f  ‘  .:  '  ‘ 

TYPE 

contoq 

END 

CONTEXT  INTERFACE  con  procs 
WITH  eg  def 
*  Control  queue  primitives  ; 

PROCEDURE  joint  VAR  q  controlq  ). 

PROCEDURE  leave(  VAR  q  controlq). 

(  Penpheral  library-  > 

PROCEDURE  switch  on  device 
PROCEDURE  switch  off  device. 

END 

Alternatively,  the  context  interlace  can  be  expressed  in  a  composite  form,  comprising  a  number  ot 

interfaces.  The  above  example  could  thus  be  expressed 
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LIBRARY  INTERFACE  cq_prims; 

WITH  cq_def; 

PROCEDURE  join(  VAR  q  :  controlq  ); 

PROCEDURE  leave(  VAR  q  :  controlq ); 

END 

The  peripheral  library  specification  could  then  be  placed  in  a  conventional  form  of  library  Interlace: 


LIBRARY  INTERFACE  periph Jib; 
PROCEDURE  switch_on_device; 
PROCEDURE  switch_off_device; 

END 


and  the  context  interface  itself  expressed  in  the  composite  form: 


CONTEXT  INTERFACE  context; 
COMPRISES  cq_prims,  periphjib; 

END 


An  access  Interface  might  feature  as  a  component  of  a  context  Interface  in  order  to  give  access 
to  an  IDA  or  server  in  the  support  software.  Special,  implementation  dependent  calling  mechanisms 
may  also  be  provided  by  the  context  through  additional  Interface  types  and  qualifiers 


The  Mascot  definition  lays  down  no  firm  rules  for  the  expression  of  context  interfaces.  The  above  are 
merely  examples  of  some  acceptable  forms  within  the  general  spirit  of  the  definition.  However,  procedure 
names  in  the  context  must  be  unique  and  any  implementation  must  define  the  context  facilities 
provided  and  the  means  for  context  extension. 
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4.2  Synchronisat i on  of  Activities 


The  Use  of  Implementation  Language  Concurrency  Facilities 


Implementation  ot  Mascot  development  environments  prior  to  the  advent  of  Mascot  3  have  invariably 
supported  programming  languages.  such  as  Coral  66,  which  make  no  provision  for  concurrency  With  the 
planned  extensive  use  of  languages  such  as  Ada,  which  include  concurrency  as  a  feature,  this  situation 
may  be  expected  to  change  Consequently  the  Mascot  facilities  described  in  this  section,  which  cater  for 
the  necessary  svrvh'on  saf.on  ot  separate  parallel  threads  of  execution,  are  to  be  regarded  as 
constituting  a  mode1  1  Ms  model  may  be  implemented  directly  in  a  conventional  programming  language, 
as  in  the  past,  ot  mapped  onto  equivalent  features  in  a  concurrent  language. 


In  any  impleme n’.T 
direct  support  hm 
appropriate  ’.rig., 
IDAs  and  servers 
activities  :.r  • 
L'nava  at’- 

have  r-o-n  . 


c*  a  ’.'ascot  development  environment  tor  which  the  application  language  provides 
■  -  y  the  implementor  should  consider  mapping  activities  onto  the 

;  me  Since  the  Mascot  definition  demands  that  the  total  network  of  activities, 
...t  t:e  invariant  at  run-time  and,  in  particular,  forbids  the  dynamic  creation  of 
•  a  whch  allow  ihe  creation  of  additional  threads  of  execution  should  be  made 
;  grammer  The  impiementor  musi  document  how  ihe  language  facilities 
■  Mascot  model  of  concurrency  and  which  facilities  have  been  suppressed. 


Any  iarVj,.  •  :  s unpods  concurrency  will  probably  also  provide  suitable  mechanisms  to 

allow  ■  . '-lunication  between  the  separate  threads  of  execution.  The  implementor 

sncuid  c,  is;  ■  !.-c, iii.es  m  this  area,  in  the  light  ot  the  Mascot  model,  to  determine  whether 

or  not  »»•..,  ■  r-  1  ;  uppc-d  inter  activity  communication  through  an  IDA  or  server  as 

pres.  :  '  '  •  ■  '  i-Cfi 


It  the  ,mp.-  .  :  .  .  cm,. nit  environment  elects  to  utilise  the  language  leatures  for  concurrency 

and  mt.-'  activity  n  the  mapping  ot  the  Mascot  activities.  IDAs  and  servers  onto  these 

larvg  ,ag.-  ?  ,  •  :  ■  *..-.nb«d  The  mechanisms  whereby  the  IDA  or  server  designer  may 

ensure  the-  r>e-  -  <•.  exclusion  and  cross  stimulation  between  separate  processing  threads  must 

also  be  dr :  u i  yt'iermore  the  use  of  these  mechanisms  should  be  restricted  to  the  access 
procedures  '  IDA  *  servers 

The  Mascot  Synchronisation  Model 

Synchronisation  ■■,  Ma:  ot  covers  the  mutual  exclusion  of  competing  processes  and  the 
cross  stimulation  M  c<  -  .■-■p*"ating  processes  t  xplicit  synchronisation  is  achieved  by  four  primitives  which 
operate  on  special  objects  called  control  queues  Since  synchronisation  takes  place  only  in  respect  ot 
access  to  IDAs  amt  servers  each  control  queue  is  conceptually  part  ot  the  structure  ot  an  IDA  or  a 
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server  Synchronisation  primitive  operations  are  only  available  within  an  access  procedure  The 
control  queue  is  defined  as  an  object  on  which  the  primitives  have  the  effects  defined  below,  and 
which  may  be  given  a  priority  specification  to  influence  the  scheduling  algorithms 

Mutual  Exclusion  -  JOIN  and  LEAVE 

Mutual  exclusion  of  competing  activities  is  effected  by  the  calls  of  the  paired  primitives  JOIN  and 
LEAVE,  each  of  which  takes  a  control  queue  as  its  single  parameter  Between  the  times  when  it 
performs  a  JOIN  operation  and  the  subsequent  LEAVE  operation,  an  activity  is  said  to  be  in  the  queue 
A  control  queue  is  said  to  be  empty  if  there  is  no  activity  in  that  queue 

JOIN  and  LEAVE  form  brackets  around  critical  sections  of  code  in  which  only  one  of  the  competing 
activities  m  the  queue  is  allowed  to  proceed.  This  activity  is  said  to  be  at  the  head  of  the  queue  and 
is  therefore  its  owner  The  use  of  the  primitive  operation  LEAVE  by  an  activity  which  is  not  the  owner  of 
the  specified  queue  constitutes  a  run-time  error  as  does  the  performance  of  a  JOIN  operation  by  an 
activity  which  is  already  the  owner  of  the  nominated  queue  An  implementation  of  a  Mascot 
development  environment  defines  the  action  that  results  It  is  recommended  that  the  occurrence  of  an 
error  be  recorded  and  that  the  activity  be  prevented  from  further  execution 

The  algorithm  that  determines  how  an  activity  reaches  the  head  of  the  queue  is  not  defined  by  the 
Definition  but  first  in  first -out  is  normal  practice.  The  algorithm  must  be  documented 

Cross  stimulation  SHM.WA1T  and  WAITFQR 

A  stimulus  response  mechanism  between  activities  is  provided  by  the  primitives  STIM  and  WAI  T  each 
of  which  takes  a  control  queue  as  its  single  parameter  An  alternative  form  of  WAIT  providing  a  time  out 
facility  is  WAIT  F  OR  which  takes  two  parameters,  a  control  queue  and  a  time  delay.  The  STIM  operatmn 
may  be  performed  at  any  time  by  an  activity,  but  the  WAIT  and  WAITFOR  operations  may  only  be 
performed  by  the  activity  which  is  the  owner  of  the  named  queue 

An  activity  which  performs  a  WAIT  operation  on  a  control  queue  is  prevented  from  continuing  ■'<: 
processing  unless  or  until,  a  corresponding  STIM  has  been  applied  to  the  same  control  queue 

A  WAIT  operation  has  one  of  two  possible  effects 

(a)  If  a  STIM  is  being  held  (see  below),  that  STIM  is  consumed  and  the  activity  is  allowed  to 

continue 

(b)  If  no  STIM  is  being  held,  the  activity  is  prevented  from  continuing  until  the  next  STIM  is 

applied 
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A  SUM  operation  has  one  ot  three  effects: 


(a)  If  there  is  an  activity  WAITing,  the  SUM  is  used  immediately  to  make  the  WAITmg 
activity  eligible  for  scheduling 

(b)  If  there  is  no  activity  WAITing,  and  no  unused  STIM  for  the  queue  is  being  held,  then 
the  STIM  is  held  for  use  by  the  next  WAIT  operation  on  the  queue. 

(c)  If  there  is  no  activity  WAITing  and  an  unused  STIM  for  the  queue  is  being  held,  then  the 
further  STIM  has  no  effect. 


The  use  of  the  WAIT  primitive  by  an  activity  which  is  not  the  owner  of  the  specified  queue  constitutes  a 
run-time  error  An  implementation  of  a  Mascot  development  environment  defines  the  action  that  results  It 
is  recommended  that  the  occurrence  of  the  error  be  recorded  and  that  the  activity  be  prevented  from 
further  execution 


The  WAITFOR  operation  is  similar  to  WAIT  except  that  the  activity  which  performs  it  becomes  eligible  for 
scheduling  on  expiry  of  the  time  delay,  given  as  a  parameter,  if  no  STIM  has  been  applied  to  the  queue 
in  the  mean  time.  The  reason  for  the  activity  being  released  from  WAITing  may  be  indicated  through  a 
function  value  return  mechanism  or  output  parameter. 


Control  Queue  Ownership  -  CHECK 


An  access  procedure  normally  contains  paired  JOIN  and  LEAVE  instructions.  This  is  known  as  a 
closed  access  protocol  and  it  forces  correct  usage.  Alternatively  an  open  protocol  may  be  used  in  which 
the  JOIN  and  LEAVE  instructions  are  contained  in  different  access  procedures.  Such  an  approach 
allows  more  discretion  to  the  application  program.  This  can  lead  to  greater  simplicity  and  an  improvement 
m  efficiency 

The  purpose  of  the  CHECK  primitive  is  to  allow  an  access  procedure  which  does  not  contain  a 
JOIN-LEAVE  pair  to  check  that  the  calling  activity  is  the  owner  of  the  nominated  queue  The  primitive 
takes  a  control  queue  as  its  single  parameter  If  the  activity  which  issues  the  CHECK  instruction  is  the 
owner  of  the  specified  control  queue,  the  CHECK  primitive  returns  control  to  the  activity  with  no 
further  action.  The  use  of  the  CHECK  primitive  by  an  activity  which  is  not  the  owner  of  the  specified 
queue  constitutes  a  run-time  error  An  implementation  of  a  Mascot  development  environment  defines 
the  action  that  results  It  is  recommended  that  the  occurrence  of  the  error  be  recorded  and  that  the 
activity  be  prevented  from  further  execution 
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4.3  DEVICE  HANDLING 


Introduction 


The  mechanisms  by  which  peripheral  devices  are  controlled  vary  significantly  from  computer  to  computer 
On  some  machines  the  contents  of  device  registers  are  manipulated  through  normal  operations  on 
specific  memory  locations  Other  machines  provide  special  instructions  for  device  control  These 
instructions  may  be  part  of  the  normal  set  available  to  all  programs  or  may  be  privileged  instructions 
requiring  a  special  mode  of  compilation  for  their  generation  from  a  high  level  language.  Thus,  modules 
which  interact  with  peripherals  may  require  special  privileges  or  facilities  not  appropriate  to  other 
modules 

in  Mascot,  as  we  have  seen  in  an  earlier  section,  the  handling  of  peripherals  is  the  domain  of  the  server, 
this  r  >e  i  class  of  template  allowed  to  contain  code  which  directly  manipulates  peripheral  control 
registers  or  which  utilises  special  facilities  provided  by  the  context  for  that  purpose.  All  the  necessary 
Abilities  may  therefore  be  made  available  automatically,  to  the  modules  which  require  them,  during  the 
const: uction  of  a  network 


One  of  the  most  important  considerations  m  connection  w  th  the  interaction  of  a  real-time  systems  with  a 
-,i C: v i e  is  whether  the  device  must  be  polled  m  order  to  detect  the  completion  of  an  operation,  or 
-t her  completion  is  signalled  by  an  interrupt  It  is  the  latter  of  these  two  options  which  is  the  more 
-in. on  and  which  requires  the  specialised  fac.lities  described  in  this  section 


interrupts 


An  interrupt  is  a  signal  generated  by  a  device  to  inform  the  processor  to  which  the  device  is  attached 
that  a  peripheral  operation  has  been  completed  its  effect,  subject  to  consideration  of  relative  priorities,  is 
"  cause  the  processor,  on  completing  the  execution  o*  its  current  instruction,  to  abandon  temporarily  the 
current  process  and  to  commence  execution  of  instructions  stored  at  a  predefined  address  This  new  set 
o!  instructions  is  called  an  interrupt  handler  Depending  on  the  computer  architecture,  a  handler  may 
be  unique  to  a  particular  interrupt  unique  to  the  priority  level  of  the  interrupt,  common  to  all  interrupts  or 
common  to  a  defined  sub  set  of  interrupts 

When  control  is  transferred  to  a  handler  the  contents  of  at  least  some  o I  the  registers  being  used  by 
the  interrupted  process  are  saved  this  is  known  as  context  switching  and  the  amount  of  information 
automatically  saved,  for  subsequent  restoration  when  the  the  process  is  resumed,  also  varies 
considerably  with  the  architecture  of  the  machine  It  may  be  as  little  as  the  value  of  the  program  counter  or 
the  context  switch  may  be  so  complete  as  to  provide  the  handler  with  its  cwn  register  set  and.  where 
appropriate,  virtual  memory  map 
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The  precise  nature  of  an  interrupt  handler  is  thus  determined  by  the  number  ot  devices  with  which  it  is 
concerned  and  the  degree  of  automatic  context  switching  which  takes  place  when  one  of  these 
interrupts  occurs.  In  order  to  minimise  the  impact  of  interrupt  handling  on  the  normal  operation  of  the 
system,  it  is  customary  to  confine  the  operations  performed  in  the  handler  to  a  minimum  Thus  for  a 
simple  device  the  next  operation  might  be  initiated  from  within  the  handler,  while  a  device  which 
requires  a  large  amount  of  data  to  be  transferred  to  or  from  it,  between  operations,  might  be  restarted 
from  elsewhere 


Interrupt  Handling  in  Mascot 


Given  the  range  of  computer  architectures  to  be  catered  for  and  the  need  tor  efficiency  in  real-time 
systems,  it  is  not  possible  to  define  a  single  mechanism  for  interrupt  handling  which  is  completely 
transportable.  Mascot  therefore  provides  a  set  of  facilities  which  allow  suitable  solutions  to  be  developed 
to  meet  a  range  of  circumstances  These  facilities  are. 


(a) 

(b) 

(c) 

<d) 

(e) 


(HANDLER) 

(CONNECT) 

(DISCONNECT) 

(ENDHANDLER) 

(STIMINT) 


the  ability  to  declare  handlers  in  server  tempates, 

the  ability  to  associate  a  handler  with  a  particular 
interrupt. 

the  ability  to  disassociate  a  handler  from  an  interrupt. 

the  ability  to  signal  completion  of  processing  of  the  cuirent 
interrupt  and 

the  ability  to  STIM  a  control  queue  from  a  handler 


Here  (a)  is  a  keyword  m  the  design  representation  language,  used  in  place  of  PROCEDURE,  and  the 
other  four  facilities  are  kernel  primitives  CONNECT  takes  two  parameters 

CONNECT(handler,  interrupt  no) 

to  identify  the  interrupt  handler  and  the  interrupt  with  which  it  is  to  be  associated,  respectively 
DISCONNECT  is  applied  to  the  interrupt  identification 

DlSCONNECT(interrupt  no) 

STIMINT,  which  is  applied  to  a  control  queue,  differs  from  STIM  (see  Section  4  2)  only  in  guaranteeing 
that  it  will  not  result  in  an  immediate  reschedule  The  documentation  of  the  run-time  system  in  a  Mascot 
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development  environment  must  describe  the  means  by  which  the  above  facilities  are  made  available 


ideally  it  should  be  possible  to  design  an  interrupt  handler  for  minimum  execution  time  and  store 
useage  without  needing  to  take  any  account  ot  the  activity  which  has  been  interrupted  However,  this 
can  only  be  achieved  where  the  hardware  provides  automatic  vectoring  to  a  handler,  uniquely 
associated  with  the  interrupt  being  serviced,  and  full  automatic  context  switching  Most  hardware  used  tor 
real  time  systems  is  not  as  sophisticated  as  this 

in  practice,  it  may  be  necessary  to  provide  some  support  in  the  Mascot  context  even  for  interrupts  which 
are  ^ONNECTed  to  handlers  located  in  the  servers  of  the  application  software.  The  following  table, 
which  differentiates  between  different  degrees  of  hardware  vectoring  to  a  particular  handler  and 
different  degrees  of  completeness  in  automatic  register  saving  and  restoring,  indicates  the  range  ot 
options 


Vectoring 

Register  Save 

Data  Transfer 

Hardware 

Hardware 

Handler  in  Server 

Hardware 

Hardware 

Access  Mechanism  In  Server 

Hardware 

Server 

Handler  in  Server 

Hardware 

Server 

Access  Mechanism  in  Server 

Hardware 

Context 

Handler  in  Context 

Hardware 

Context 

Handler  in  Server 

Hardware 

Context 

Access  Mechanism  in  Server 

Context 

Context 

Handler  in  Server 

Context 

Context 

Access  Mechanism  In  Server 

Context 

Server 

Handler  in  Server 

Context 

Server 

Access  Mechanism  in  Server 

Context 

Context 

Handler  in  Context 

in  the  above  table  Server'  is  used  to  denote  a  server  in  the  application  software  The  term  Context 
should  be  taken  to  include  the  possibility  of  a  server  in  the  context 

Design  Considerations 


There  are  a  number  of  considerations,  some  of  them  imposed  by  the  computer  architecture  which 
influence  the  design  of  interrupt  handlers  and  their  execution  Three  of  the  most  significant  issues  are 
discussed  below 

Nesting  of  Interrupts 

Devices  may  be  classified  on  a  scale  of  priorities  such  that  a  handler,  in  course  of  execution,  may  itself 
be  interrupted  by  a  device  possessing  a  higher  priority  When  the  higher  priority  interrupt  has  been 
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handled,  control  returns  to  the  handler  of  the  lower  priority  interrupt  before  eventually  being  returned  to 
the  onginally  interrupted  activity  Several  levels  of  priority  may  be  catered  tor  in  this  way  In  such 
circumstances  it  is  acceptable  for  the  individual  handlers  to  be  somewhat  more  complex  since  their 
execution  does  not  lock  out  higher  prionty  interrupts  Control  is  still  taken  away  from  the  software 
scheduler,  however,  and  more  stack  space  is  required  to  provide  local  storage  for  the  handlers  than  in 
the  non  nested  case 

Stack  Management 

Local  working  space  for  a  handler  may  be  provided  from  the  stack  of  the  interrupted  activity  This 
avoids  the  necessity  of  switching  stacks  when  control  passes  to  or  from  a  handler  However,  it  also 
means  that  every  activity  stack  must  be  large  enough  to  accommodate  the  maximum  possible  depth  of 
interrupt  nesting  if  this  is  employed  Alternatively,  a  separate  stack  may  be  allocated  either  to  each 
handler  or  to  each  level  of  interrupt,  again  allowing  for  interrupts  to  be  nested,  or  a  single  stack  can  be 
shared  by  all  handlers  if  there  is  no  nesting 

Pre-emption 

After  an  interrupt  has  been  handled  (ENDHANDLER),  control  may  be  returned  to  the  interrupted 
activity  or,  alternatively,  the  interrupted  activity  may  be  transferred  to  the  current  lists  and  control 
passed  to  the  Mascot  scheduler  (see  Section  4  4)  The  latter  strategy  results  in  the  better  system 
response  at  the  possible  cost  of  a  slight  reduction  in  throughput  If  it  is  adopted,  a  further  question  arises 
as  to  whether  the  interrupted  activity  should  be  added  to  the  head  or  the  tail  of  the  current  list  If  it  is 
placed  at  the  tail  this  results  in  a  'round-robin'  scheduling  operation  within  a  priority  level  (there  will 
normally  be  a  current  list  for  each  level)  Placing  it  at  the  head  of  the  list  may  be  regarded  as  more  'fair' 
since  then  each  activity  is  allowed  to  complete  its  slice  of  execution  before  any  other  activity  of  the 
same  pnonty  is  scheduled  Notice  that  this  is  not  the  same  as  the  co-operative  mode  of  scheduling  as 
higher  priority  activities  are  allowed  to  run  at  any  point 
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4.4  SCHEDULING  AND  PRIORITIES 


Introduction 

in  any  concurrent  system  where  the  number  of  parallel  processes  exceeds  the  number  of  processors,  a 
scheduling  function  is  required  to  allocate  processing  time  amongst  the  competing  processes  Each 
processor,  periodically,  must  cease  the  execution  of  one  process  and  commence  execution  of  another 
Associated  with  these  re  schedule  points  there  are  two  decisions  which  have  to  be  made.  The  first  is  to 
determine  when  the  current  slice  of  execution  on  a  given  processor  is  to  end  and  the  second  is  to  select 
which  process  is  to  be  allocated  the  next  slice  It  is  normal  practice  to  assign  a  priority  level  to  each 
process  to  assist  in  determining,  for  the  purposes  of  the  second  of  these  decisions,  which  of  a  number  of 
waiting  processes  is  the  most  urgent  The  choice  of  scheduling  strategy  is  usually  governed  by  the 
desire  to  optimise  the  response  to  external  events  for  a  given  amount  of  processing  power. 

!n  these  respects  Mascot  systems  are  the  same  as  any  other  concurrent  system.  The  Mascot  definition 
lot ’S  not  prescribe  the  use  of  any  particular  scheduling  strategy  though  it  does  require  that  the  selected 
•rategy  be  documented  for  the  information  of  users  of  the  development  environment.  The  choice  of 
hoduling  algorithm  is  deliberately  left  to  the  implementor  in  order  lo  allow  the  optimum  algorithm  for  the 
application  to  be  adopted  The  more  important  of  the  possible  schedul.ng  and  priority  schemes  are 
d-pcussed  below  in  Mascot  terms 

Co-Operative  and  Pre-Emptive  Scheduling 

jne  o'  the  major  factors  affecting  the  responsiveness  of  a  concurrent  system  is  the  basic  mode  ot 
scheduling  adopted  co  operative  or  pre-emptive  Under  a  co-operative  regime  reponsibi lity  tor  the  first  ot 
'.'it-  two  scheduling  decisions,  slice  termination,  is  vested  in  the  application  rather  than  in  the  Mascot 
“■erne i  An  activity  continues  its  slice  ot  execution  until  it  volunteers  to  give  up  the  processor  by 
evoking  one  ot  the  kernel  primitives  This  may  be  one  ot  the  scheduling  primitives  such  as  JOIN  (on  a 
jOINed  control  queue)  or  WAIT  WAlTFOR  (on  an  unSTIMmed  control  queue)  or  a  re  schedule  may 
be  invited  more  directly  by  means  of  the  SUSPEND  primitive 

Provision  of  SUSPEND  is  mandatory  m  a  development  environment  which  supports  co  operative 
scheduling  Its  use  guarantees  re  scheduling  provided  that  there  is  at  least  one  activity,  ot  at  least  equal 
pnon'y  waiting  to  run  If  there  are  no  such  schedulable  activities  the  activity  issuing  the  SUSPEND  is 
entered  for  another  slice  ol  execution 

Development  environments  which  support  the  timing  group  (see  Appendix  E)  of  primitives  provide 
another  means  of  directly  surrendering  the  use  of  a  processor  This  is  the  DELAY  primitive  which  lakes  a 
rime  penod.  in  implementation  defined  units  as  its  argument  An  activity  invoking  DELAY  is  not 
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considered  for  re  scheduling  until  the  nominated  period  has  elapsed  irrespective  ot  whether  there  are 
other  schedulable  activities  or  not.  The  other  primitive  in  the  timing  group  is  TIMENOW  which  is  a 
function  returning  current  system  time  The  units  and  range  of  system  time  are  implementation  defined 

There  are  two  other  synchronising  primitives  whose  use  mav.  even  under  co-operative  scheduling,  result 
in  a  re-schedule  These  are  are  LEAVE  and  STIM  when  they  have  the  effect  of  releasing  an  activity 
which  has  previously  been  held  up  The  decision  on  whether  to  reschedule  in  these  circumstances  is 
implementation  defined 

Under  a  co-operative  regime  it  is  guaranteed  that,  immediately  after  an  interrupt  has  been  handled,  a 
reschedule  will  not  take  place  Control  is  always  returned  to  the  interrupted  activity.  This  mode  of 
working  tends  to  minimise  the  time  spent  in  performing  context  switches;  an  important  consideration  on 
hardware  in  which  the  context  switch  is  inefficient  It  also  leads  to  simplification  of  the  kernel  code  and,  in 
the  application,  exclusive  use  of  a  resource  can  be  guaranteed  without  recourse  to  special  synchronising 
primitives  such  as  JOIN  and  LEAVE.  There  are.  however,  complicating  effects.  Contrary  to  the  normal 
Mascot  philosophy  the  activity  programmer  must  take  account  of  the  execution  time  ot  any  long 
sequences  ot  code  and  add  calls  on  SUSPEND  at  strategic  points  in  order  to  avoid  taking  excessively 
long  slices  This  is  generally  unsatisfactory  and,  indeed,  the  overheads  imposed  by  frequent  calls  on 
SUSPEND  may  cancel  the  original  gains  In  the  limit,  a  faulty  activity  containing  a  closed  loop  would 
bring  the  remainder  of  the  system  to  a  halt  unless  the  kernel  clock  handler  checks  for  processor  hogging 
and  takes  action  to  TERMINATE  the  offending  activity 

Co-operative  working  effectively  limits  the  ability  of  the  scheduler  to  optimise  the  system's  response  The 
alternative  is  pre-emptive  scheduling  under  which  the  kernel  is  free  to  re-scheduie  following  an  interrupt 
The  arrival  ot  an  interrupt  is  an  event  which  is  likely  to  alter  the  state  ot  the  system  An  activity  which  has 
been  awaiting  this  interrupt  may  well  have  become  the  most  urgent  Under  pre-emptive  scheduling,  it  can 
be  entered  for  execution  without  delay  An  activity  which  is  hogging  a  processor  is  less  damaging  than 
under  a  co  operative  regime  though  it  may  still  be  detected  and  TERMINATEd  The  opportunity  of 
re-schedulmg  after  a  clock  interrupt  makes  time  slicing  possible  by  setting  a  maximum  slice  time 


Priority  Schemes 


The  simplest  priority  scheme,  it  it  can  properly  be  so  called,  is  one  in  which  all  activities  are  given  the 
same  priority  A  single  current  list  containing  all  the  currently  schedulable  activities,  is  maintained  on  a 
first-in  first-out  basis  The  scheduler  always  selects  the  activity  which  has  been  waiting  longest,  that  is. 
the  activity  at  the  head  ot  the  list  This  scheme  is  the  fastest  possible  in  execution  but  provides  little 
scope  for  improving  the  response  of  the  system  to  external  events  Indeed  this  can  only  be  achieved  by 
the  crude  mechanism  of  adding  calls  on  SUSPEND  in  order  to  increase  the  number  ot  re  schedule 
points  As  the  length  of  the  current  list  cannot  be  determined  by  an  activity,  such  a  strategy  is  not  very 
effective  and  may  in  addition  prove  wasteful  of  processor  resources  if  carried  to  excess 
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in  the  next  priority  scheme  to  be  considered,  several  priority  levels  are  employed  to  which  all  activities 
are  allocated,  once  tor  all.  on  first  being  executed  A  first-in  first  out  list  is  maintained  for  each  priority  level 
and  these  are  scanned  by  the  scheduler  in  priority  order  to  select  the  activity  at  the  head  of  the  first 
occupied  list  The  choice  thus  falls  on  the  most  urgent  task  which  has  been  waiting  the  longest 
Compared  with  the  single  priority  approach,  this  strategy  results  in  greater  flexibilty  at  the  expense  of 
greater  complexity  and.  in  general,  a  heavier  drain  on  processor  time  It  possesses  the  advantage  that  the 
response  to  external  events  can  be  tailored  by  changing  the  relative  priority  levels  ot  activities  without 
altering  the  coding  of  any  templates  The  response  problem  is  not,  however,  totally  solved  since  no 
matter  how  high  its  priority  level  an  activity  may  be  held  up  in  the  pending  list  of  a  control  queue 
behind  one  of  lower  priority 

'■  sally  m  an  attempt  to  overcome  this  problem  ot  the  collision  of  two  activities,  of  different  priorities, 
no! mg  tor  ownership  ot  a  control  queue  multi-level  priority  schemes  may  be  extended  to 
,  mp.mm  dynamically  vanng  priorities  Cross-stimulation  between  co-operating  activities  is  net 
^touted  Although,  at  first  sight,  variable  priorities  may  seem  to  present  an  added  complexity,  they  can  be 
--a  to  use  in  practice  than  fixed  priorities  This  is  because  a  priority  level  can  be  associated  with  a 
■  r:;e  m  such  a  way  as  to  reflect  its  scarcity  and  this  is  often  easier  to  assess  than  the  average  urgency 
-  >  r-cutlrig  a  particular  activity  Two  of  the  many  possible  algorithms  which  may  be  used  to  determine 
,  :  ■■••es  m  this  type  of  scheme  are  discussed  below 

■  •  o  pr-ority  may  oe  associated  with  a  control  queue  Any  activity  which  JOINS  such  a  queue 
.  mes  this  priority  if  it  is  higher  than  its  own  current  priority  The  activity's  priority  reverts  to  its  previous 
•  'Auen  the  control  queue  is  released  This  scheme  is  relatively  easy  to  implement  although  the 
••  -.'  ration  ot  priority  on  t  FAVb  can  present  some  difficulties  if  multiple  JOINS  and  LEAVES  are  not 
' ■  d  it  does  however,  complicate  the  coding  ot  the  primitives  and  extend  the  execution  time  required 
,  "JIN  and  LEAVE  Also  the  lower  priority  activities  execute  at  higher  priority  than  is  desirable  when 
"i  m-  13  no  collision 

A  .  a  blither  refinement,  control  queue  priority  may  itself  be  made  variable.  Initially  minimum  priority  is 
allocated  and  the  priority  of  an  activity  JOINmg  the  queue  is  not  atlected  However  when  an  activity  is 
Oa-.ed  on  the  pending  list,  the  priority  of  the  control  queue  is  set  to  the  higher  of  its  own  and  that  of 
activity  Thus  the  priority  ot  the  queue  owner  is  maintained  as  that  of  the  highest  priority  activity  in 
trie  queue  The  queue  reverts  to  minimum  priority  when  the  pending  list  becomes  empty  The  result  is 
that  activities  are  executed  at  their  assigned  priorities  except  when  in  collision  with  a  higher  priority 
activity  This  improvement  is  achieved  at  the  cost  ot  further  complication  of  the  code  and  increased 
execution  time  for  JOIN  and  LEAVE 
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4.5  MULTI-PROCESSOR  CONFIGURATIONS 


Introduction 

Multi-processor  target  configurations  for  Mascot  applications  can  be  classified  in  a  variety  of  ways  on  the 
basis  of  their  distinguishing  characteristics.  They  may  differ,  for  example,  in  respect  of  any  of  the 
following: 

(1)  Inter-Processor  Relationships.  There  are  three  principal  types  of  configuration. 

One  processor  may  be  designated  as  master  with  all  others  acting  as  slaves.  A  symmetrical  arrangement 
of  identical  processing  elements  is  possible  in  which  the  storage  and  input/output  resources  of  the 
system  are  all  shared.  Finally  the  processors  may  operate  autonomously  each  with  its  own  private  set  of 
resources 

(2)  Memory  Visibility.  The  possibilities  here  are  that  the  system's  memory 

resources  may  all  be  accessible  to  all  processors,  may  be  divided  into  units  each  of  which  is  available  for 
use  by  one  processor  only  or  a  combination  of  these  arrangements  may  be  employed  with  a  mixture  of 
common  and  private  storage. 

(3)  Number  of  Mascot  Kernels.  Multi-processor  configurations  may  contain  a  single 

copy  of  the  Mascot  kernel  or  many  copies,  tor  example  one  per  processor. 

(4)  Allocation  of  Activities.  The  selection  of  a  processor  for  the  task  of 

executing  a  Mascot  activity  may  be  performed  on  either  a  static  or  a  dynamic  basis. 

It  is  also  possible  to  envisage  complex  configurations  employing,  within  the  same  system,  more  than  one 
of  the  possibilities  listed  under  (1)  and  (4)  above.  Two  classes  of  configuration  using  at  least  some  shared 
memory  are  discussed  below,  those  configurations  employing  a  single  Mascot  kernel  being  considered 
first  and  then  those  with  multiple  kernels  Finally  configurations  with  no  shared  memory  are  discussed 
very  briefly 

The  following  discussion  is  in  terms  of  a  control  queue  based  implementation  Similar  considerations 
apply  to  any  alternative  run-time  implementation  strategy  and.  when  considering  such  alternatives,  'he 
arguments  should  be  interpreted  accordingly 


Single  Kernel  Configurations 


In  a  master/slave  arrangement,  the  single  kernel  has  one  processor,  the  master,  dedicated  to  its 
execution  and  so  need  not  be  re-entrant  The  diagram  below,  which  illustrates  this  configuration,  shows 
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two  slave  processors  although  there  might  be  any  number  The  simplest  example  of  this  arrangement, 
where  there  is  just  one  slave  processor,  comes  nearest  to  the  familiar  single  processor  case  and,  in 
general,  the  software  configuration  is  simple 


As  the  kernel  data  are  accessible  to  only  one  processor  no  protection  is  required.  Equally,  an  activity 
t:e>ng  executed  on  a  slave  processor  has  no  direct  access  to  kernel  facilities  and  some  software 
mechanism  must  be  provided  to  permit  such  activities  to  invoke  primitive  operations.  Some  common 
memory  is  therefoie  essential 

in  a  symmetrical  arrangement,  the  processing  elements  are  identical  and  almost  all  memory  and 
nput  output  facilities  must  be  common  A  three  processor,  symmetrical  configuration  is  illustrated  in  the 
diagram  below  The  common  store  contains  the  system's  single,  multi  thread  kernel.  Separate  copies  of 
read  only  components  may  be  held  in  local  memory  for  efficient  access  while  there  is  potential  lockout  on 
shared  kernel  data  and  the  application's  control  queues  must  be  protected  for  concurrent  access  Control 
of  the  kernel  passes  from  one  processor  to  another  but  only  one  can  be  'master'  at  any  one  time  An 
activity  could  be  executed  on  different  processors  for  different  slices 

A  maior  advantage  of  this  type  of  configuration  is  that  the  workload  of  the  processors  is  balanced.  If  one 
processor  fails,  the  system  is  able  to  continue  with  reduced  performance  or  with  support  for  some  of  its 
functions  withdrawn.  Extra  processors  can  be  added  with  minimal  rebuilding  This  is  an  attractive 
arrangement  provided  sufficient  common  memory  can  be  made  available  without  significant  access  time 
penalty 
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Multiple  Kernel  Configurations 


Providing  each  processor  with  its  own  copy  ot  the  Mascot  kernel,  in  private  memory,  leads  to  the 
autonomous  arrangement  (illustrated  below)  in  which  the  processors  act  independently  and  the  kernels 
perform  almost  as  in  a  single  processor  configuration  Each  processor  has  private  input/output  devices 
but  some  shared  memory  is  desirable  Activities  are  assigned,  permanently,  to  a  particular  processor  at 
build-time.  Kernel  data,  such  as  tor  example  pending  lists,  may  need  to  be  shared  between  kernels. 

The  key  consideration  which  further  distinguishes  configurations  of  this  type  is  the  means  by  which 
application  or  context  software  running  on  one  processor  can  communicate  with  software  running  on 
another  processor.  At  the  most  fundamental  level,  communication  between  processors  can  be  by  polling 
or  can  be  interrupt  driven  At  a  level  more  relevant  to  the  present  discusson  the  choice  is  between 
communication  effected  directly  by  the  application  software  or  by  the  kernel  acting  on  its  behalf.  The 
extent  of  the  common  memory  available  is  one  important  factor  in  determining  the  method. 


4.5  Multi-Processor  Configurations 


4-  15 


Mascot  Version  3. 1 


Communication  between  Mascot  activities  involves  access  procedures,  control  queues  and 
IDA  data.  With  total  support  from  the  kernel  and  given  an  adequate  amount  of  shared  memory, 
communication  among  activities  assigned  to  different  processors  may  take  place  in  a  wholly  transparent 
way  The  sharing  ot  IDA  data  presents  no  problem  The  sharing  ot  access  procedures  avoids 
duplication  of  code  at  the  cost  of  the  additional  access  time  associated  with  common  memory.  It  is  the 
sharing  of  control  queues  which  requires  special  support  from  the  kernel 

When  all  primitives  are  available  for  application  to  shared  control  queues,  the  pending  list  of  such  a 
queue  may  contain  activities  whose  execution  is  administered  by  different  kernels  Ownership  of  the 
queue  passes  from  one  kernel  to  another  A  kernel  needs  to  be  aware,  therefore,  when  one  of  the 
activities  under  its  control  has  been  STIMmed  remotely  dhat  is.  by  an  activity  running  on  another 
processor).  This  information  can  be  supplied  by  polling  or  by  interrupt 

The  mam  advantage  of  such  an  arrangement  is  that  a  component  of  the  application  software  can  be 
relocated  for  execution  by  a  different  processor  without  any  changes  being  necessary  to  its  source 
template.  On  the  other  hand,  the  need  to  hold  pending  lists  in  shared  memory  and  the  continual 
change  of  processor  owning  a  shared  control  queue  is  not  very  desirable  for  efficient  and  fault-tolerant 
operation 

An  alternative  approach  is  one  in  which  inter-processor  communication  is  restricted  to  the  ability  of  an 
access  procedure,  running  on  one  processor,  to  apply  a  STIM  to  a  control  queue  controlled  by  the 
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kernel  ot  another  processor  The  pending  list  tor  such  a  queue  only  contains  activities  which  belong 
to  the  local  kernel  so  that  ownership  ot  the  queue  remains  with  a  single  kernel  Thus  while  IDA  data  are 
shared,  pending  lists  can  be  held  in  local  memory  1  he  operation  ot  a  remote  STIM  involves  drawing  the 
attention  ot  the  local  kernel  to  the  tact  that  a  WAlTmg  activity,  under  its  control,  is  now  available  for 
scheduling  or,  it  there  is  no  activity  WAlTmg  on  the  queue  and  no  previous  STIM  being  held  on  that 
queue,  that  there  is  now  a  STIM  to  be  held  tor  future  use.  All  that  need  be  communicated,  in  order  to 
convey  this  information,  is  the  identity  ot  the  control  queue  involved.  This  can  be  done  through 
shared  memory,  allowing  all  the  control  queues  to  be  held  in  local  memory 

This  method  reduces  the  overheads  ot  a  multi  processor  target  to  a  minimum  However,  communications 
restrictions  between  processors  prevent  the  'processor  boundaries'  from  being  transparent  to  the  design 
and'or  implementation  of  the  application  Thus  changes  in  the  distribution  of  components  may  require 
changes  to  the  network 

Communication  Linked  Configurations 


Finally  it  should  be  mentioned  that  multi  processor  working  may  take  a  form  in  which  there  is  no  common 
memory  Communication,  m  this  case  is  effected  by  a  'communications  bearer'  such  as  a  local  area 
network  (LAN)  independently  ot  the  kernel  Somo  support  may  however,  be  offered  by  the  context 
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4.6  EXECUTION  CONTROL 


Introduction 


In  this  section  the  execution  control  facilities  which  are  mandatory  in  a  Mascot  development  environment 
are  presented  first  There  follows  a  discussion  of  the  additional  facilities  which  it  is  desirable  should  be 
provided  to  support  software  commissioning.  A  set  of  commands  is  then  described  for  the  application  of 
control  functions  to  individual  activities.  IDAs  and  servers.  Finally  further  additional  facilities  are 
described  which  support  the  hierarchic  control  of  networks 

Mandatory  Facilities 

When  a  Mascot  system  has  been  built,  each  of  its  components  is  said  to  be  in  an  unestablished 
state  Before  any  constituent  activity  can  be  executed  it  is  necessary  that  it,  and  the  IDAs  and  servers 
to  which  it  is  connected,  be  initialised  Part  of  the  process  of  establishing  an  IDA  or  server  is  the 
execution  of  any  initialisation  procedure  contained  When  a  component  has  been  successfully  initialised, 
it  achieves  the  state  value  of  established.  An  established  activity  may  be  started  once  all  the  IDAs 
and  servers  to  which  it  is  connected  have  been  established  Thus,  the  minimum  necessary  set  of 
execution  control  facilities  consists  of  INITIALISE  which  establishes  a  component  and  START  which  sets 
an  established  activity  running  All  Mascot  development  environments  must,  therefore,  support  these 
two  functions.  The  corresponding  state  change  diagram  is  given  below 


An  activity  enters  the  crashed  state  after  a  fatal  run  time  error  has  been  detected 
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The  two  mandatory'  functions  may  be  provided  either  as  par*  of  the  build-time  facilities  or  as  on-line, 
run-time  commands.  The  mechanism  ot  the  former  approach  is  implementation  defined  In  the  latter  case, 
unless  the  mechanism  is  automatic,  the  functions  should  be  made  available  through  an  appropriately 
named  interface  which  may  be  defined  either  as  part  of  the  context  or  as  an  application  module  Any 
parameters  will  be  expressed  in  a  form  which  is  consistent  with  the  other  language  facilities  A 
development  environment  may  also  provide  a  command  interpreter  which  uses  the  interface. 

Additional  Non-Mandatorv  Facilities 

While  the  mandatory  facilities  descnbed  above  fulfil  the  minimum  requirements  for  an  operational  Mascot 
system,  additional  facilities  are  desirable  during  the  software  commissioning  phase  of  a  project  A 
Mascot  development  environment  may  therefore  provide  four  further  functions,  HALT,  RESUME 
RESET  and  TERMINAL  E  which  should  be  made  available  as  on-line,  run-time  facilities.  Associated  with 
these  functons  :s  a  further  state  halted  The  full  state  change  diagram  is  shown  below 


The  halted  state  is  entered  as  a  consequence  ot  the  application  of  the  HALT  function  While  in  the 
halted  state  an  activity  is  not  eligible  for  scheduling  although  a  timeout  may  expire  or  the  activity  may 
become  the  owner  of  a  control  queue 
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The  full  Mascot  definition  allows  activities,  as  well  as  IDAs  and  servers,  to  contain  initialisation 
procedures  (see  Appendix  E),  Termination  procedures  may  also  be  included  in  all  three  of  these 
module  classes  and  reset  procedures  may  be  included  in  IDAs  and  servers  Where  such 
procedures  are  catered  for  in  a  Mascot  development  system,  their  execution  is  initiated  as  part  ot  the 
INITIALISE,  RESET  and  TERMINATE  functions.  Note  that  once  INITIALISE  has  been  applied  it  cannot  be 
re-applied  without  first  returning  to  the  unestablished  state  by  means  of  TERMINATE.  The  reset 
procedures  of  IDAs  and  servers  may,  however,  be  executed  in  the  established  state  by  means  of 
the  RESET  function 

The  functions  HALT .  RESUME  and  TERMINATE  are  not  normally  considered  to  be  suitable  for  use  in  an 
operational  system  because  of  their  drastic  side  effects.  In  the  case  of  HALT,  an  activity  is  prevented 
from  further  execution  until  RESUMEd  If  the  activity  is  executing  an  access  mechanism  of  an  IDA  or 
server,  this  may  prevent  ether  activities  completing  execution  of  access  mechanisms  in  the  same 
IDA  or  server,  and  hence  will  potentially  stop  the  remainder  ol  the  system  The  operation  of 
TERM  NATF  also  has  drastic  side  effects  in  that  an  activity  may  be  aborted  while  executing  an  access 
maechanism  This,  in  general,  can  result  in  the  contents  of  IDAs  or  servers  becoming  inconsistent 
While  these  side  effects  are  tolerable  during  software  commissioning,  they  are  not  normally  tolerable 
during  system  operation  If  there  is  no  alternative  to  the  use  of  HALT  TERMINATE,  it  may  be  necessary  to 
introduce  special  facilities  to  prevent  the  side  effects 


Command  Description 


1  he  INITIAL  IS E  F  unction 

if  we  assume  all  its  components  to  be  m  the  unestablished  state,  a  complete  system  may  be 
initialised  in  the  following  manner  hirst  the  INITIAL  SSL  function  is  applied  to  each  IDA  and  server  If  the 
operations  are  successful  all  these  components  will  become  established  It  is  then  possible  to 
establish  the  activities  by  applying  the  INITIAL  ISE  function  to  each  of  them  in  turn  Tins  ordering  may 
be  relaxed  where  it  is  guaranteed  that  the  initialisation  code  within  an  activity  does  not  interact  with  any 
of  the  IDAs  or  servers  to  which  it  is  connected 

The  effect  of  applying  the  INITIALISATION  function  is  to  cause  the  initialisation  procedure  to  be 
executed  After  successful  application  of  the  INITIAL  ISA7ION  function  an  activity.  IDA  or  server  is  m 
the  established  state 

A  run  time  system  may  place  restrictions  on  the  facilities  available  to  an  initialisation  procedure  provided 
that  these  restrictions  are  documented  In  particular,  since  the  initialisation  procedure  may  be  invoked  by 
the  run  time  system  rather  than  by  an  activity  it  may  be  inappropriate  to  use  the  control  queue 
pnmitives  other  than  STIM  or  STIMINT 
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In  a  development  environment  which  supports  the  INI  I IAI  function  on  line  there  must  be  at  least  one 
parameter,  namely  the  activity,  IDA  or  server  identity  whose  preferred  form  is  defined  by  the  syn'ax 

diagram  below 


The  system  name  me.  t>>  cm  "•  :  n>  •  *  /.*>•  system  s  allowed  so  tfiat  there  .« 

no  possible  ambiguity 

if  the  passing  of  a  parameter  to  IDA  r»  server  ■  :  i  •  i  ,ce  •«  suppo'h  the"  n  •  ••  >  ;• 

specitiying  the  value  to  be  c ar •  -.1  w  ■  t  ••  :  W".-...,  ,1  •-mm.e'rt  interpreter  ■  «  prc.  g.-i  " 

command  will  tal-.e  the  form  s f ' o  wn  t  •  ■  i : 


The  ST  AR  T  F  unction 

The  START  function  can  only  be  applied  to  an  activity  wv  *,  i-  u  the  established  :  tate  and  ‘  r  ,%r-  j 
all  the  connected  IDAs  and  servers  are  also  established  The  effect  cf  its  successtu1  applicat.cn  .s  to- 
put  the  activity  into  the  running  state  and  to  mb-tm  the  heduler  that  the  activity  is  ei  giMe  tc 
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scheduling  from  its  initial  entry  point 


In  a  development  environment  which  supports  the  START  function  on  line,  the  (unction  accepts  either 
one  or  two  parameters  These  are  the  element  identity  and.  it  the  development  environment  supports 
priority  change  at  start,  a  priority  value  Where  a  command  interpreter  is  provided,  the  command  will  take 
the  form  shown  below 


Where  a  priority  value  is  mvepted  it  overrides  the  the  priority  specified  during  building  If  dynamic 
priority  adjustment  is  supiorfed  this  value  may  itself  subseguently  be  overridden  If  the  START  function 
cannot  be  apple.-  f  'o  the  activity  then  an  error  or  warning  message  will  be  generated  to  specify  the 
idenf  :,  c*  "it.-  activity  ana  t*  -•  reason  tor  the  failure  f  or  example 

S'ARl  I  noi  Activity  SI  ARIL  1ST  F  If.  f  f  R  .s  crashed 

SI  ART  Warning  Activity  MMI  COMMANDIN I  already  running 

i he  criterion  wn-t  ieterm,nes  the  nature  ct  the  message  is  whether  the  desired  effect  has  been 
achieved  or  no'  Thus  attempting  to  s  r  AR  r  a  running  activity  should  generate  a  warning  while 
attempting  *o  .y  ’  Afx  ’  a  crashed  activity  should  result  m  an  error  message 

'  •  *  A;  •  l  urii  tier- 

I  he  ha;  '  ”■  i,  ,  ,k  activity  a"  -h  n  me  running  state  Its  effect  is  to  put 

the  activity  /■"'  i  halted  ?t  tie  ar  t  '  •i.'crm  the  c  c ctk  or  'fiat  ttie  activity  is  not  eligible  for 
f-'V.Tutmg  When  a  .  •  nmi  kwI  ifs-rp tales  the  form 


I  he  function  accepts  i  crvj'o  parameter  wtu.  h  s  the  •ilvtihty  ot  the  activity  to  be  halted  I!  the  function 
cannot  be  applied  to  an  activity  then  a  warning  is  generated  to  specify  the  activity  identity  and  the 
reason  'cr  the  failure  t  or  example 


MAS  I  Warning  Activity  si  A!;;!  ist  III  If  R  ain  a"y  halted 


The  Rf  SUM!  I  •.me*  n 


The  Rf  SUMT  function  may  only  he  applied  to  an  activity  which  is  in  the  halted  state  Its  ettei  f  is  to  put 
the  activity  into  the  running  state  and  to  inform  the  scheduler  that  the  activity  is  now  eligible  ’or 


4  6  Execution  Control 


4  22 


Mascot  Version  3  1 


scheduling  Where  a  command  interpreter  is  provided  the  command  takes  the  form 


The  function  accepts  a  single  parameter  which  is  the  identity  ot  the  activity  to  be  resumed  It  the 
RESUME  function  cannot  be  applied  to  the  activity  then  an  error  or  warning  message  will  be  generated 
to  specify  the  activity  identity  and  the  reason  tor  the  failure  For  example: 


RESUME  Error  Activity  STABILISE  FILTER  is  crashed 
RESUME  Warning  Activity  MMI  COMM/vNDINT  already  running 


The  TERMINATE  Function 


The  TERMINATE  (unction  can  be  applied  to  an  activity  which  is  in  any  state  but  unestabllshed  If  IDA 
or  server  termination  procedures  are  supported  then  TERMINATE  may  be  applied  to  an  established 
IDA  or  server  provided  that  all  connected  activities  are  either  unestabllshed  or  established. 


The  effect  ot  the  T'  RMINAfF  function  applied  to  an  activity  is  to  put  it  into  the  unestablished  state 
and  inform  the  scheduler  that  the  activity  is  not  eligible  tor  scheduling  The  activity  is  removed  from  all 
internal  queues  and  it-?s  within  the  run  fme  executive  and  is  removed  from  all  control  queues  it  has 
lomed 


Where  a  command  interpreter  is  provided  the  command  takes  the  form 


TERMINATE  element  identity 


The  funcf.rm  a  .  •  ;■  k  a  ;  r  parameter  which  is  the  identity  ot  the  activity  IDA  or  server  to  be 
terminated 

The  effect  ot  R'e  Tl  RM'NA  r[  i-rut  on  applied  to  an  IDA  or  server  is  to  execute  the  term  apron 
procedure  if  such  e  •  uppoded  bv  the  development  environment 

It  the  Tf  RMINATI  function  t  annct  t>>  applied  to  an  activity  IDA  or  server  then  an  error  or  warning 
message  will  be  generated  to  rpe<  /y  the  identity  and  the  reason  to.  the  failure  For  example 

If  RMINATI  f  rror  Channel  SIARII  iSt  MFSSCHAN  is  connected  to  running 
*  f:  ,~t: >  -s 

H  KM  NAM  Warning  Activity  S  T  APIUSf  SHIR  is  unestabllshed 
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The  RESET  Function 


The  RESET  tunction  may  only  be  applied  to  IDAs  and  servers  which  are  in  the  established  state  Its 
effect  is  to  cause  the  execution  of  the  reset  procedure  and  it  leaves  the  element  established  Where  a 
command  interpreter  is  provided  the  command  takes  the  form 


The  second  parameter  •»  prov-ded  is  passed  to  the  reset  procedure  If  the  RESET  function  cannot  be 
applied  to  an  IDA  or  server  then  an  error  message  will  be  generated  to  specify  the  identity  and  the 
reason  tor  the  failure  F  or  example 

•'?  Si  T  Lire-'  IDA  ST  AI3IL.SK  MESSCHAN  is  unestablished 

The  REST  I  tun.-fen  provides  a  means  of  reinitialising  an  IDA  or  server  without  needing  to 
FbRMINAIF  the  associated  activities 

Hierarchic  Control  Facilities 

vc n;r;i  > ••  d.-  --  Ted  above  opera'e  on  individu;.  elements  Mascot  de.elcpnvrt 

environments  r,  a*  be  extended  to  support  hierarchic  control  ct  systems  subsystems  and 
composite  IDAv  .1  servers  '  k,e«e  tac.'.hes  operate  by  app.ymq  the  functions  already  closer:.  ’ 
r*'.\<rsivriy  ’  *’  o  elements  are:  io.v.r  levei  networks  w  th.”  a  .ti-'d  network  x.ntdv  P-r  •* 

these  featia* r.-  ,..*.s  !.«*“•  t.-ime  ex’-re.ions  to  ;r>»>  ♦.  .;r  ;v-«vr  p:  »;f'c  and  these  ar.  :t  ■  :  v  ■ .  ; 

below 


A  development  .  n.ircniMin!  if  requ  r..q  ••■>  1.  *e»,.  in.  e't-  t  ct  j-  ,iii-rarcl:,ca.  cc-nf  c  or-  e  .*  '  '>q  •  ; 

operate  A  much  wider  range  ot  exceptional  sitaat;  "s  <  .n  >  our  such  a:  ter  ex.vrp  •  >  «»,♦•  a;-f  '  it  ;• 

the  Rf  St  IMF  turn  ’o  n  to  a  network  At>  ti  contam'  i  crashed  activity  "  •  ■  w-rm  u  »•  iq  "  i*  m  <  . 
components  of  a  network  van  be  in  did.-mot  states  n-ak-nq  (tie  >  *vept  ot  an  ov.  <ail  network  <•  ■••• 
meaningless 

Mierarcftic  identity 

The  preferred  form  o<  identity  described  above  te  r  activities  IDAs  arid  servers  nue  t  t ,t''.  <■  ;  •. 

allow  the  omission  ot  trailing  fields  the  function  is  then  applied  to  the  named  t  *uu  t-.jre  If  f.-r  p . 

the  possibilities  tor  error  actions  applying  to  the  system  a«.  a  whole  should  require  the  system  name  to 
be  specified  it  could  however  still  be  omitted  tor  subsystems  and  composite  IDA<  .cd  servers 
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INITIALISE  Applied  Hierarchically 


The  hierarchic  form  of  the  INITIALISE  function  should  first  initialise  all  the  IDAs  and  servers  and  then  the 
activities  of  the  network  being  initialised.  If  the  development  environment  is  not  capable  of 
determining  the  necessary  order  of  initialisation  according  to  the  dependencies  then  it  must  provide  a 
mechanism  for  speci'yng  this 

The  development  environment  must  define  the  method  of  handling  parameters  of  initialisation 
procedures 

START  Applied  Hierarchically 

The  development  environment  must  define  how  the  start  priority  value  is  to  be  interpreted  in  connection 
with  a  system  or  subsystem 

HAl  T  RESUME  and  TERMINATE  Applied  Hierarchically 

The  order  ot  application  must  be  defined  for  the  development  environment  If  these  functions  are 
provided  by  means  of  an  interlace  which  is  accessible  to  the  application  then  the  development 
environment  must  ensure  correct  operation  when  a  command  is  issued  by  an  activity  which  is  itself 
withm  the  scope  ot  that  command 

Rf  Sf  1  Appin'd  Herun'hioa'lv 

The  hierarchic  form  of  RESE  T  is  similar  to  the  hierarchic  form  ot  INITIALISE  except  that  it  only  affects  IDAs 
and  servers  Again  the  development  environment  must  define  the  method  of  handling  parameters 
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4.7  ERROR  HANDLING 


Introduction 


As  stated  m  the  introduction  io  inis  Handbook.  Mascot  is  aimed  primarily  at  the  development  oi  reai  time, 
embedded  software  Such  applications  usually  demand  a  high  degree  of  fault  tolerance.  In  the  face  c*  a 
wide  range  of  run  time  errors,  systems  are  expected  to  continue  operation,  albeit  in  a  degraded  mode  in 
which  some  functions  are  no  longer  available  or  are  available  at  reduced  efficiency.  Error  detection  and 
hand'tng  are  therefor*  of  considerable  importance  in  the  operational  software.  During  the  development 
stage,  it  is  essential  to  have  good  •  triples  tor  error  reporting  and  for  some  applications  this  facility  must  be 
retained,  possibly  m  a  mod  h-.-o  term,  when  the  system  becomes  operational. 

the  t.vee  functions  detector.,  handling  ana  reporting  involve  actions  at  three  levels  of  the  system:  the 
hardw  are  '  o.ecjtivo  software  ; the  Mascot  kernel;  and  the  application  software 

Mascot  Error  Handling  Requirements 

Errors  may  be  detected  at  all  three  levels  and  handled  bv  either  of  the  software  levels.  At  the  hardware 
level  such  events  as  arithmetic  overflow  or  underflow  and  memory  protection  violation  are  detected  and 
normally  signalled  by  means  ot  an  interrupt  mechanism  .Response  to  these  signals  may  be  provided  by 
'her  the  executive  or  the  application  software  In  the  case  ot  the  application  level,  the  coding  which 
checks  tty-  har  i.ve'e  status,  for  errors  may  be  programmed  explicitly  or  may  oe  included  implicitly  by  the 
vOmpil.it. on  system 

Other  errors  are  detected  dreebv  by  the  software  The  executive  detects  such  faults  as  ‘he  illegal  use  ot 
pr.mitives  and.  under  a  co-operaiive  scheduling  regime  an  excessive  time  slice.  In  the  application 
software  checks  may  be  made  explicitly  for  errors  related  to  the  logical  significance  of  the  program  * 
•.'«amp!e  might  be  a  mutually  inconsistent  set  of  data  values  For  a  wide  range  of  errors,  the  division 
netween  those  which  must  be  catered  tor  explicitly  and  those  which  are  automatically  trapped  by  code 
embedded  by  the  compiler,  depends  heavily  on  which  implementation  language  is  being  used  and  its 
provisions  tor  data  typing  Languages  such  as  Pascal  and  Ada  provide  the  programmer  with  a  great  deal 
more  assistance  in  these  matters  than,  for  example.  Coral  66  Range  checks  on  individual  values  fall  into 
"  r  category 


1 '  the  question  ot  handling  the  error  once  it  tias  been  detected,  this,  in  fault  tolerant 
em.-iy  tne  responsibility  of  the  application  software  Consequently,  error  handling  in  the 
■  •  r  st  error  signals  originating  from  the  hardware  or  of  directly  detected  errors,  normally 
:  "  ••  •  to'mai.on  on  to  the  application  In  a  few  instances  however,  the  executive  may 
i  ■  r  is  a  manner  which  is  transparent  to  the  application  In  a  paging 
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implementation,  a  page  fault  could  be  dealt  with  in  this  way  In  other  cases,  where  the  error  is  too  serious 

for  recovery,  the  execution  thread  containing  the  error  may  be  aborted  and  a  message  transmitted  to  the 
error  reporting  system.  Where  an  error  has  been  detected  by  or  communicated  to  the  application 
software,  the  mechanism  whereby  control  is  passed  to  the  appropriate  handling  code  is  again  very 
language  dependent  with  Ada.  PL/1  and  RTL/2  providing  built-in  facilities  of  varying  degrees  of 
sophistication 

The  Mascot  definition  calls,  under  various  circumstances  (see  for  example  Section  4  2),  for  the 
generation  of  error  or  warning  messages.  Concern  with  the  foregoing  is  otherwise  limited  to  the 
possibility  that  analysis  ot  the  message  may  be  used  to  trigger  recovery  action.  A  Mascot  development 
environment  is  required  to  provide  error  reporting  facilities  which  may  be  used  by  both  the  executive  and 
application  parts  ot  the  software  in  a  uniform  manner.  These  facilities  are  defined  in  terms  of  three 
elements  an  error  notification  interface  an  error  channel  and  a  standard  error  reporting 
network  Support  for  *hese  elements  is  mandatory  only  during  development  and  not  in  an  operational 
Mascot  system 

Example  Error  Handling  Facility 

In  this  section  error  reporting  facilities  are  described,  for  convenience,  in  the  form  of  a  particular 
implementation.  This  implementation  is  not  pad  of  the  standard.  The  documentation  of  a  Mascot 
development  environment  must  specify  the  precise  mechanisms  which  are  supported  and  suitable 
means  of  amending  these  facilities  should  be  provided 

The  diagram  below  illustrates  how  the  standard  facilities  could  be  provided 
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The  purpose  of  the  network  is  to  take  messages,  convert  them  to  a  suitable  textual  form  and  transmit 
them  to  an  appropriate  device  Messages  passed  to  the  network  are  stored  initially  in  a  channel  of  type 
mascot_ error_ chan  Input  is  via  a  window  which  provides  the  standard  error  notification 
Interface  which,  in  our  example,  has  been  named  report  error 


ACCESS  INTERFACE  report_error; 

PROCEDURE  errorfmessage  :  text_string;  . ); 

PROCEDURE  fatal_error(message  :  text_string;  . ); 

END 


Thus  there  are  to  be  two  access  procedures  error  and  fatal_error  each  of  which  place  in  the 
channel  a  message  which  contains,  in  addition  to  the  text  itself  (possibly  represented  by  an  error 
number),  an  indication  of  the  severity  of  the  fault  and  the  identity  of  the  activity  which  originated  the 
message  (or  on  whose  behalf  it  was  originated  by  the  executive).  Other,  user  generated,  components 
may  also  be  included  in  the  message  The  procedures  may  take  other  parameters  as  defined  in  the 
documentation  of  the  development  environment. 


Procedure  fatal_error  has  the  additional  effect  of  setting  the  state  of  the  activity,  in  which  the  fault 
has  occurred,  to  crashed  and  informing  the  scheduler  that  the  activity  is  no  longer  eligible  for 
scheduling.  In  the  above  example  network  these  actions  are  represented  by  a  port  which  propagates 
information  out  of  the  error  channel  If  the  activity  is  selected  for  monitoring,  calling  either  access 
procedure  will  result  in  the  generation  of  an  appropriate  monitor  record  (see  Section  4.8) 


The  error  channel  provides  an  output  window  of  type  mascot  error  to  give  access  to  the 
messages  which  have  been  generated  by  the  system.  The  access  interface  takes  the  form: 

ACCESS  INTERFACE  mascot_error; 

WITH  error  message: 

PROCEDURE  get  error(VAR  message  error  message:  . ); 

END 

where 

DEFINITION  error  message; 

TYPE 

severity  =  (error,  fatal); 
error  message  =  RECORD 

text  :  text  string; 
faultjype  :  severity; 
act  :  act  id; 


Any  additional  parameters  of  access  procedure  get_error  are  defined  for  the  Mascot 
implementation. 
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The  development  environment  documentation  will  also  define  other  characteristics  of  the  error 
channel  including  its  behaviour  when  full,  the  queuing  algorithms  (eg  priority  levels  of  messages)  and 
the  behaviour  where  no  consumer  activity  is  connected  to  the  channel. 

The  standard  error  reporting  network  is  required  to  contain  facilities  for  taking  messages  from  the 
error  channel,  via  the  mascoterror  window  converting  them  to  textual  form  and  transmitting  them 
to  the  output  device  via  a  window  of  type  mascot_text_out  In  our  sample  system  these  facilities  are 
illustrated  as  an  activity  text_formatter  with  access  to  a  message  pool  and  connected  to  a  server 
window  of  the  appropriate  type.  Access  interface  mascot_text_out  is  of  the  form: 


ACCESS  INTERFACE  mascot_text_out ; 
PROCEDURE  text_put(mess  :  text  string); 

END, 


The  format  of  the  message  displayed  by  the  device  is  as  follows 

activity  identity  error  type  error  message  parameter's) 
where  the  preferred  form  of  an  activity  identity  is 
subsystem  name  activity  name 

The  'error  type'  takes  its  value  from  the  severity  component  of  the  message  (error'fatal)  and  any 
additional  parameters  must  be  defined  for  the  implementation 

It  should  be  possible  for  the  user  to  adapt  the  standard  error  reporting  facilities  by  replacing  the  server 
and/or  replacing  the  processing  element.  In  the  latter  case  the  application  error  handling  might  analyse 
the  error  message  and  determine  some  network  level  recovery  action.  For  example,  receipt  of  a  warning 
message  that  a  channel  has  reached  95%  of  capacity  might  trigger  an  action  to  filter  incoming  data  more 
heavily  in  the  hardware  and  so  reduce  the  number  of  events  being  processed 
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The  problems  of  testing  and  diagnosis  in  a  real-time,  multi-threaded  system  differ  considerably  from  those 
encountered  during  the  corresponding  phase  in  the  development  of  a  sequential  program  In  particular, 
the  standard  interactive  tools  will  usually  be  inappropriate  in  that  it  is  neither  possible  nor  desirable  to 
suspend  execution  of  the  system  or  to  execute  it  in  single  step  mode.  The  Mascot  approach  encourages 
the  planning  of  testing  and  diagnosis  during  the  design  phase  of  a  project  and  a  Mascot  run-time  system 
should  provide  a  range  of  facilities  to  assist  in  this  aspect  of  the  design. 

The  use  of  the  set  of  facilities  provided  for  this  purpose  is  known  as  monitoring  and  the  primary  purpose  is 
to  collect  and  display  an  ordered  i»«~*  of  significant  interactions  within  a  system  being  commissioned. 
These  interactions  may  be  between  the  elements  of  the  system  or  between  these  elements  and  the 
context  It  is  obviously  desirable  that  the  collection  of  this  data  should,  as  far  as  possible,  be  a  function 
of  the  run-time  system  rather  than  of  the  application  software.  The  monitoring  facility  should  provide, 
therefore,  a  means  of  recording  the  interactions  without  the  need  to  incorporate  special  code  in  the 
application  templates 

The  basic  concept  employed  in  Mascot  is  that  the  collection  of  monitoring  information  should  be 
decoupled  from  the  processing  and  display  of  that  information.  The  recommended  collection  system 
maintains  the  time  ordering  of  the  information  gathered  and  is  designed  to  have  a  minimal  impact  on  the 
normal  execution  of  the  components  under  investigation.  The  remaining  facilities  include  provision  for 
selecting  subsets  of  the  possible  information  and  the  means  of  processing  the  gathered  data  and 
displaying  it  in  a  readable  form. 

Monitoring  is  presented,  in  this  section,  in  the  form  recommended  for  a  run-time  system  which  supports 
the  Mascot  primitives  (see  Section  4.2).  For  a  run-time  system  which  does  not  support  these  primitives, 
some  form  of  monitoring  facility  should  still  be  provided.  In  this  latter  case,  the  range  of  events  to  be 
monitored  is  more  difficult  to  define  but  is  likely  to  be  broadly  similar. 

Events  to  be  Monitored 

In  a  run-time  system  which  supports  the  Mascot  primitives,  the  events  which  would  be  candidates  for 
monitoring  include  the  following 
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Control  Queue  Primitives;  Timing  Erimitives 


JOIN 

DELAY 

WAIT 

TIMENOW 

WAITFOR 

Interrupt  Related  Primitives: 

LEAVE 

CONNECT 

STiM 

disconnect 

STIMINT 

ENDHANDLER 

CHECK 

Interrupt  occurrence 

Occurrence  of  Errors: 

ERROR 

FATAL  .ERROR 

Scheduling  Operations; 

Selection  of  ar  activity  for  scheduling  (START  SLICE) 

Ending  of  period  of  activity  execution  (ENDSLICE) 

Tracing  of  Control  Flow 

Automatic  recording  (where  provided  for  by  the  compiler)  of  such  events  as 
procedure  entry  and  return  (TRACE) 

Miscellaneous  Primitives 

SUSPEND 

ENDROOT 


The  monitoring  facility  also  provides  a  mechanism  for  recording,  in  addition  to  the  events  listed  above, 
application  specific  events  (record  points).  This  mechanism  is  known  as  the  RECORD  facility  and  is 
normally  provided  in  the  form  of  one  or  more  primitives  which  have  implementation  defined  parameters. 

Selection 


In  even  the  smallest  application,  the  volume  of  data  gathered  and  displayed  by  the  monitoring  facility  is 
potentially  overwhelming.  It  is  therefore  necessary  to  be  able  to  select  sub  sets  from  the  totality  of 
monitorable  events  The  control  mechanisms,  recommended  for  this  purpose,  provide  a  set  of  filters 
which  select  the  desired  sub-set  dynamically.  Experience  has  shown  that  the  most  useful  criteria  are: 

Which  activities  are  to  be  monitored? 

Which  primitives  are  to  be  monitored? 

Which  control  queues  (where  relevant)  are  to  be  monitored? 

Which  record  points  are  to  be  active? 

Is  the  automatic  trace  data  (if  any)  to  be  recorded? 
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For  an  event  to  be  recorded,  all  of  the  relevant  selections  must  be  in  force  Thus,  lor  a  control  queue 
primitive,  the  control  queue,  the  primitive  and  the  activity  must  all  be  selected 

The  recommended  control  facilities  are  provided  by  the  operations  SELECT  and  EXCLUDE  which 
respectively  extend  and  reduce  the  set  of  events  to  be  recorded  These  operations  require  two 
parameters  The  first  of  these  is  the  identity  of  the  group  to  which  it  applies 

ACTIVITY 
PRIMITIVE 
CONTROL  Q 
RECORD 
TRACE 


and  the  second  is  the  identity  of  the  member  of  that  group.  The  recommended  form  of  reference  to 
activities,  control  queues  and  record  points  is  by  the  element  identity  as  de'ired  in  Section  4  6  of 
the  Handbook  extended  by  the  addition  of  the  structure; 

controlq  name 

to  the  identity  of  the  IDA  or  server  containing  the  control  queue,  and  by  the  addition  of  the  structure: 
record  point_name 

to  the  identity  of  the  element  containing  the  record  point. 

The  hierarchic  form  of  element  identity,  described  in  the  Section  4  6,  may  be  used  as  a  shorthand  means 
of  SELECTing  or  EXCLUDmg  a  collection  of  activities,  control  queues  or  record  points  in  a  single 
operation  Thus,  by  the  omission  of  trailing  fields,  reference  can  be  made,  for  example,  to  all  the 
activities  in  a  subsystem,  all  the  control  queues  in  an  IDA  or  all  the  record  points  in  an  activity 

Identification  of  the  TRACE  records  to  be  monitored  is  entirely  dependent  on  the  identification 
information  which  the  development  system  associates  with  each  trace  point 

Primitives  should  be  selected  by  the  names  used  under  the  heading  of  'Events  to  be  Monitored'.  The 
term  SLICES  should  be  used  to  represent  the  START  SLICE,  END  SLICE  pair,  and  ERRORS  to 
represent  ERROR  and  FATAL  ERROR. 


4.8  Monitoring 


4-  32 


Mascot  Version  3.1 


Group  references  may  be  supported  in  a  Mascot  monitoring  tacilty  through  the  keywords 
ALLPRIM  -  All  primitives 

ALLACT  All  activities 

ALLCQ  -  All  control  queues 

ALL  RECORD  -  All  record  points 

All  selections  remain  in  force  until  explicitly  excluded  by  means  of  the  EXCLUDE  function 

It  will  be  appreciated  that  there  are  some  elements  of  any  system  which  must  not  be  selected  for 
monitoring  The  operations  of  the  monitoring  facility  itself  are  an  example  The  system  builder  should 
therefore  provide  facilities  to  inhibit  monitoring  of  nominated  activities  and  control  queues  These 
inhibitions  should  be  transmitted  to  the  run-time  monitoring  system  and  should  be  used  to  override  the 
effects  of  individual  selection  of  the  specified  items  or  the  effects  of  ALLCQ  and  ALLACT 

In  summary,  the  parameters  of  the  SELECT  and  EXCLUDE  functions  are: 

PRIMITIVE  primitive  name 

AC  i  iVITY  activity  name 

RECORD  record  point  name 

TRACE  (additional  parameters  implementation  dependent) 

ALLACT 

ALLCQ 

ALLPRIM 

ALLRECORD 

SLICES 

ERRORS 


Recordin< 


It  is  recommended  that  the  events  selected  for  recording  by  a  Mascot  monitoring  system  are  written  into 
the  monitor  buffer,  in  strict  order  of  occurrence,  in  one  of  the  following  nodes: 

REALTIME 
IN  LINE 

In  the  default  mode  of  IN  LINE,  all  the  selected  events  are  captured  If  necessary  execution  of  the 
activities  being  monitored  is  held  up  in  order  to  ensure  that  no  monitoring  information  is  lost  In  this 
mode  of  operation  it  is  permissible  to  disallow  selection  of  interrupf  and  scheduling  events 
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In  REAL  TIME  mode  snapshots  of  the  monitored  events  are  taken  while  the  system  is  allowed  to  run  with 
the  minimum  of  interference  Data  are  written  to  the  monitor  buffer  until  it  becomes  full  When  this  has 
happened,  all  further  monitor  data  are  discarded  until  the  contents  of  the  buffer  have  been  processed  lor 
display.  The  number  of  monitored  events  lost  in  this  way  should  be  reported  to  the  processing  function 

X hroa  ft  irfhar  r\r\1in»nc  aro  rarr.mmanH o/H  tr>r  Ihrv  CO yVvTO !  ro^rxrHi  r->g 

HOLD 

EMPTY 

OFF 

HOLD  prevents  further  entnes  being  written  to  the  monitor  buffer  while  preserving  the  current  contents 
Further  data  are  discarded  until  REAL  TIME  or  IN_  LINE  mode  is  selected. 

EMPTY  clears  the  butter  and  causes  further  data  to  be  discarded  until  REAL  TIME  or  INLINE  mode  is 
selected 

OFF  disables  all  monitoring  (both  recording  and  processing)  until  REAL  TIME  or  IN  LINE  mode  is 
selected 

These  five  options  may  be  selected  using  the  SELECT  operation  with  the  appropriate  parameter 

Processing 


The  function  of  processing  is  to  convert  the  coded  information  in  the  monitor  buffer  into  a  readable  form 
and  display  it  by  means  of  a  suitable  penpheral.  Facilities  must  be  provided  to  perform  this  either  on-line  or 
off-line 

The  on-line  facility  allows  processing  to  be  turned  either  on  or  off.  It  is  controlled  by  the  SELECT  and 
EXCLUDE  operations,  in  the  normal  way,  using  the  keyword  PROCESS.  While  processing  is  disabled,  it 
is  recommended  that  the  contents  of  the  monitor  buffer  be  circularly  overwritten  in  either  REAL_TIME  or 
IN  LINE  mode  of  operation  This  ensures  that  the  buffer  always  contains  a  record  of  the  most  recent 
events  ready  for  processing  and  display  as  an  aid  to  problem  diagnosis 

The  off-line  facility  should  permit  the  contents  of  the  monitor  buffer  to  be  examined  following  a  system 
crash 
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5.1  METHOD  AND  USE 


Introduction 


This  section  describes  the  method  whereby  a  desiqr  may  be  derived  through  the  use  ot  the  Mascot 
design  representation  language  and  graphical  notation  set  out  in  earlier  sections  of  the  Handbook  The 
domain  of  applicability  o!  Masco!  includes  the  development  and  Subsequent  maintenance  ot  software  for 
large,  distributed,  embedded,  real  time  data  processing  systems  Without  excluding  the  possibility  of 
applying  sub  sets  of  the  notation  and  the  method  to  smaller  systems  Mascot  places  particular  emphasis 
on  the  word  'large'  Large,  that  is  in  the  sense  of  large  numbers  of  people  involved  in  the  development  a 
large  amount  ot  program  text  to  be  written  a  large  number  ot  requirements  to  be  serviced  simultaneously 
a  great  vanety  and  quantity  ot  hardware  resources,  and  a  protect  whose  development  extends  over  a  long 
time  scale  The  adoption  ot  this  emphasis  on  large  systems  has  resulted  in  the  evolution,  m  Mascot  of 
the  techniques  necessary  for  handling  the  scale  and  complexity  which  seem  to  be  inescapable  features 
ot  modern  software  developments 


The  Mascot  design  method  provides  a  basis  tor  managing  both  the  concurrency  in  development  which 
arises  when  many  people  are  deployed  simultaneously  on  a  task,  and  the  iteration  which  arises  when 
lower  level  design  causes  previously  taken  higher  level  design  decisions  to  be  changed.  The  method 
can  be  viewed  as  a  process  where  there  are  multiple  sites  ot  execution  and  where  earlier  stages  may 
need  to  be  revisited 


Development  Management 


The  Mascot  method  is  based  on  the  progressive  and  repeated  application  of  a  simple  buf  powerful 
technique  that  of  alternating  the  requirement  and  design  viewpoints  in  the  course  of  establishing  an 
hierarchic  structure  At  each  level  of  decomposition,  a  design  is  postulated  to  meet  a  set  ot  requirements. 
Implementability  is  thus  k>  pt  firmly  in  mind  when  elaborating  the  design  structure.  This  encourages  a 
closed  loop  approach  to  the  development  process  whereby  the  (unctions  provided  and  the  performance 
achieved  by  a  design  at  any  level  can  be  related  directly  and  easily,  to  a  corresponding  set  ot 
requirements 

Great  emphasis  is  placed  on  design  visibility  throughout  software  development.  This  is  achieved  by  using 
the  various  composite  structures  to  give  an  hierarchic  form  ot  design  definition  In  this  way  large 
problems  can  be  partitioned  to  contain  the  complexity  at  any  point  in  the  design,  and  to  allow  work  to  be 
shared  amongst  members  of  a  team  Skill,  experience  and  good  management  are  required  during  this 
process  which  is  essentially  creative,  but  is  highly  visible  and  amenable  to  control 
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Mascot  is  not  prescriptive  thus  it  does  not  provide  any  recipes  tor  establishing  or  tilling  out  the  framework 
tor  a  given  design  problem  However  it  does  permit  integration  with  a  wide  range  ot  complementary 
software  system  analysis  and  design  methods  In  this  way  the  benefits  ot  Mascot  structural  descnption 
and  development  control  can  be  combined  with  the  advantages  provided  by  other  well  proven  or 
emerging  software  engineering  techniques 


Design  Decomposition 


Each  software  component  ot  a  Mascot  system  is  derived  from  a  template  and  for  every  template  there 
is  a  uniquely  defined  design  task  The  Mascot  method,  therefore,  includes  stages  which  relate  to  specific 
classes  ot  templates  the  operational  system,  networks,  elements  or  subelements,  simple 
templates  and  test  systems  each  of  these  stages  is  further  elaborated  in  terms  of  substages.  The 
diagram  below,  in  which  each  bo*  represents  a  substage,  summarises  the  common  approach  used  in  all 
stages 


functional  External 

Requirements  Interactions 


General  Decomposition  Diagram 


At  any  point  in  the  decomposition  process  a  design  is  postulated  which  will  satisfy  the  external 
interactions  and  functional  requirements  derived  from  earlier  stages  Each  external  interaction  is  an 
identifiable  set  of  operations  and  or  data  flow  constraints  and  each  functional  requirement  specifies  a 
transformation  which  relates  to  operational  and  or  data  (low  effects  on  one  or  more  interactions  Design 
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decomposition  at  any  stage  identities  a  set  of  components  each  with  its  own  functional  r.*qu>r^r-r..-r 
and  interactions  For  each  software  component  the  requirements  tor  the  corresponding  template  am 
then  derived  (substage  3)  together  with  its  interactions  (substage  4)  These  in  turn  lead  to  the  function"! 
requirements  and  external  interactions  lor  further  decomposition  Note  that  the  Mascot  graphical 
conventions  give  explicit  identification  of  interactions  a  dashed  line  indicates  interaction  between  a 
component  and  a  device,  a  path  indicates  an  interaction  within  a  network  and  a  link  indicates  an 
interaction  within  an  element 

A  template  has  to  be  designed  to  meet  functional  requirements  and  to  service  or  generate  external 
interactions  which  are  determined  by  previous  stages  of  the  design  Thus,  for  example,  the  design  of  the 
operational  system  may  place  requirements  and  interaction  constraints  on  a  component  subsystem 
whose  template  in  turn  places  requirements  and  interaction  constraints  on  a  component  element 
The  element  template  may  be  further  decomposed  and.  in  the  process,  places  requirements  and 
interaction  constraints  on  component  subelements 

In  the  decomposition  of  a  template  (substage  1)  the  following  are  identified  any  hardware  elements  to 
be  employed,  the  software  components  and  the  internal  interactions  The  characteristics  of  the  hardware 
elements  are  described  in  substage  2  The  template  specification  and  functional  requirements  for  each 
component  are  defined  in  substage  3.  The  sema  tic  and  dynamic  properties  of  the  internal  interactions 
are  defined  in  substage  4  while  the  syntax  of  the  interfaces  is  defined  in  substage  7.  Finally,  the 
functional  requirements  and  interactions  associated  with  testing  the  template  are  defined  in  substages 
5  and  6 

The  results,  with  the  exception  of  those  produced  by  substage  2,  flow  forward  as  data  for  lower  levels  of 
decomposition  The  complete  design  process  is  bounded,  at  the  beginning,  by  the  given  framework  in 
which  development  is  to  take  place  and.  at  the  end.  by  programmirq  the  indivisible  elements  and 
subelements  which  form  the  atoms  of  the  design,  and  by  designing  test  systems  for  each  of  the 

templates 

Technical  Authority 

From  a  development  management  point  of  view,  the  responsibilites  relating  to  each  design  task  (each 
template)  may  be  expressed  in  the  roles  played  by  a  designer  and  a  technical  authority.  The  designer  of 
a  template  is  responsible  for  carrying  out  all  the  substages  relevant  to  the  template  design  task 
These  include  the  integration  of  the  components  identified  in  the  template  in  order  to  be  satisfied  that 
the  template  requirements  and  interaction  constraints  have  been  met  The  technical  authority  for  a 
template  is  responsible  for  design  task  definition  and  for  the  verification  and  acceptance  of  the  work 
earned  out  by  the  designer  of  that  template 
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Normally  the  technical  authority  tor  a  template  will  be  the  designer  ol  the  enclosing  template  (in  which 
it  is  identified)  This  ensures  that  the  technical  authority  is  responsible  for  all  the  requirements  and 
interaction  constraints  relevant  to  the  design  task  to  be  undertaken  by  the  designer,  these  include. 

(a)  Interaction  Descriptions  These  are  the  definitions  of  the  data  flows  and  operations 
on  the  paths,  links  and  device  interactions  which  components,  to  be  created 
from  the  template  must  generate  or  respond  to  (that  is  the  output  from 
substage  4  of  a  previous  design  task) 

(b)  Interlace  Specifications  These  are  the  formal  specifications  of  the  procedures  in 
the  Mascot  Interface  modules  (that  is  the  output  ol  a  previous  substage  7). 

id  Template  Functional  Requirements  These  define  the  transformations,  expressed 
.n  terms  ct  toe  interactions  described  above,  to  be  carried  out  by  any  component 

created  ucm  the  template 


Some  formality  must  be  attached  to  trie  transfer  ot  work  between  a  technical  authority  and  a  designer. 
Before  a  design  task  is  placed  by  a  technical  authority  on  a  designer,  a  Requirements  Review  must  be 
earned  out  The  formality  of  this  review  will  be  dependent  on  the  extent  of  the  definition  detail  at  the  time 
the  design  task  is  initiated  Mascot  allows  work  to  proceed  against  incomplete  design  definitions  .lor 
example,  with  specification  modules  at  registered  status  only)  and  this  partial  statement  ;f 
requirements  must  be  subiect  to  some  sort  of  review  Later,  when  full  specifications  are  availably  i 
more  thorough  review  can  be  undertaken 

When  the  design  task  has  been  completed  a  Verification  and  Acceptance  Review  mm :  r  • 

This  will  involve  at  the  least  a  review  ot  all  the  substages  of  the  design  tail-  •  ■ 

Verification  Analyses  and  Acceptance  fests  may  be  undertaken  at  this  pemt 

Design  Definition 

The  principal  Structural  features  of  Mar  t  .,••• 
decomposition  from  systems  tlr..x.y>  network  ■-  r 
paths  and  links  being  identified  on  the  w  i. 

At  the  top  of  the  structure  are  the  ~p- ■■  c ■  •  •  sys'e-  o 

meet  primary  operational  requ. •  s>s.  . 

components  tor  sc  n  ■ 

between  templates  >■  *  comporr-w 
IS  evolved  mV”’ 

F  a  h  componor  i 
Interface  sper  ■*  •  v 
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multiple  components  derived  from  the  same  template,  or  the  creation  of  the  same  type  of 
component  in  different  execution  environments  for  prototyping,  testing  or  re-use. 


Design  Structure 


The  principle  of  'containment  of  complexity'  should  ruthlessly  be  applied  during  design  structure 
elaboration.  At  each  stage  of  decomposition  a  significant  measure  of  partitioning  should  be  achieved  but 
without  generating  overly  complex  internal  component  structures.  The  final  hierarchical  design 
structure  should  contain  the  minimum  number  of  levels  consistent  with  the  ability  to  see  easily  how  each 
component,  at  any  level,  plays  its  part  in  satisfying  the  requirements  generated  by  the  next  level  up. 

Application  '  the  Mascot  method  is  likely  to  result  in  a  large  number  of  names.  These  names  must  be 
chosen  with  care  and,  in  the  case  of  very  large  systems,  it  may  be  necessary  to  introduce  special  naming 
conventions  and/or  measures  to  limit  the  potentially  global  scope  of  template  names.  The  value  of 
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clear,  meaningful  names  cannot  be  over  emphasised.  Template  names  should  reflect  the  general 
functional  capability  of  a  module,  whereas  component  names  should  be  chosen  to  indicate  the 
particular  role  of  the  component  in  the  composite  module. 

Not  shown  in  the  diagram  are  various  additional  modules  which  are  not  involved  in  the  primary 
decomposition  in  terms  of  networks,  elements  and  subelements  The  set  of  additional  modules 
and  the  purpose  for  which  they  are  required  is  as  follows: 

(a)  Context  Interface.  This  defines  the  operating  environment  of  the  Mascot 
software. 

(b)  Library  Interface.  This  defines  a  set  of  facilities  to  be  provided  by  a  library 
component  within  the  application  software.  It  may,  on  occasions,  represent  the 
existence  of  a  piece  of  (possibly  custom  designed)  hardware. 

(c)  Library  Template.  This  defines  a  set  of  library  algorithms. 

(d)  Definition.  This  defines  one  or  more  data  types  and  associated  constants. 

(e)  Build  Modules.  These  define  the  mapping  of  software  design  components  onto 
target  hardware. 

During  developmt  ...  the  definition  of  the  design  structure  will  evolve  in  parallel  and  be  subject  to  iterative 
change.  This  process  will  be  recorded  in  the  Mascot  database  using  the  status  progression  facilities. 
The  Mascot  database  is  similar  t"  a  Data  Dictionary  but  has  far  more  emphasis  placed  on  the 
relationship  between  entries.  The  structure  at  any  time  captures  the  current  state  of  the  design  and 
allows  assessment  of  the  degree  of  completion. 

The  quality  of  the  documentation  at  the  end  of  development  will  significantly  affect  the  maintainability  of 
the  system  and  the  potential  of  any  of  its  templates  for  re-use.  When  the  development  task  is  'finished', 
the  documentation  set  must  include  the  rationale  for  the  'final'  structure.  Those  parts  of  the  design  which 
have  been  discarded  during  the  iterative  development  process  need  not  be  retained  in  full,  although  the 
history  of  the  development  and  any  major  lessons  learnt  should  be  summarised  in  a  design  record. 

Potential  for  Re-use. 

Mascot  is  essentially  a  form  of  software  template  technology.  The  output  from  the  decomposition 
process  (substage  1)  expresses  the  design  in  terms  of  the  functionality  of,  and  interactions  between,  the 
components.  When  the  interactions  are  defined  (substage  4)  their  descriptions  are  generalised  so  as 
to  maximise  the  potential  for  re-use.  In  the  same  way,  in  the  definition  of  the  template  (substage  3),  the 
transformations  to  be  performed  by  any  component  derived  from  the  template  are  expressed  in  terms 
of  the  generalised  interactions  derived  above.  It  is  possible  to  identify  a  number  of  circumstances 
frequently  encountered  when  designing  a  template  for  a  particular  component: 
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(a)  Unique  Template.  This  is  where  a  template  must  be  designed  from  scratch 
Nothing  exists  (or  there  is  no  knowledge  of  it)  which  can  be  used  as  a  starting 
point  for  the  template  design. 

(b)  Adapted  Template.  This  is  where  a  template  can  be  designed  using  an  existing 
template  as  the  base  line  for  the  development. 

(c)  Common  Template.  This  is  where  a  common  requirement  exists  at  several 
different  places  in  the  overall  design  structure  and  where  it  is  possible  to  satisfy 
this  requirement  with  a  common  design.  Control  of  the  common  design  should  be 
exercised  from  at  least  the  lowest  common  point  above  the  places  where  it  is  used 
in  the  design  hierarchy.  A  common  template  may  be  parameterised  in  various 
ways,  or  may  be  produced  in  variant  forms  using  automatic  program  generation 
techniques,  to  give  some  flexibility  in  use. 

(d)  Standard  Template.  This  is  similar  to  a  common  template,  but  with 

applicability  across  a  range  of  projects. 

(e)  Existing  Template.  A  existing  unique  or  adapted  template  may  be  adopted  for 

use  elsewhere.  In  being  so  used  it  is  made  into  a  common  or  standard 

template  and  control  of  its  design  should  be  exercised  accordingly.  Whenever  it 
is  decided  to  make  use  of  an  already  existing  template  it  is  likely  that  this  will  to 
some  extent  affect  the  interactions  and  component  requirements  in  the  enclosing 
design  structure;  these  must  now  be  tailored  to  accomodate  the  existing  item 

Design  stgges 

As  already  indicated,  the  design  process  can  be  broken  down  into  a  number  of  stages  and  substages 
This  must  not  be  construed  as  a  linearisation  of  the  essentially  iterative  and  concurrent  design  actions 
which  take  place  in  a  large  software  development.  However  some  means  of  identifying  different  aspects 
of  the  design  process  is  needed  and  it  is  for  this  reason  that  the  stages  and  substages  are  defined,  each 
being  given  a  number  for  ease  of  reference.  Thus,  although  the  work  of  a  development  will  not  proceed 
strictly  in  accordance  with  the  stage  numbering,  the  sequence  indicates  the  order  in  which  the  design  of 
individual  items  is  elaborated 


The  rationale  for  the  'final'  design,  or  any  design  which  is  thought  to  be  good  at  any  particular  point  of 
development,  may  well  give  the  impression  that  it  has  been  arrived  at  by  orderly  sequential  application  of 
the  design  stages.  Indeed  it  is  important  that  it  is  possible  to  describe  the  design  in  This  way  The  Mascot 
method  is  specifically  geared  to  the  problems  of  controlling  the  evolution  of  a  design,  during  which 
mistakes  may  be  made  and  requirements  changed.  The  method  maximises  the  formality  with  which  an 
evolving  design  structure  can  be  expressed,  whilst  maintaining  flexibility  by  allowing  changes  to  be  made 
in  well  defined  localised  regions. 
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Before  embarking  on  the  first  stage  of  the  design  it  is  necessary  to  begin  by  establishing  the  framework  in 
which  the  development  will  take  place.  Although  work  on  this  is  started  right  at  the  beginning  of  the 
project  it  is  likely  that  the  bulk  of  the  detail  will  need  to  be  deferred  until  the  first  stage  of  decomposition 
has  been  completed.  Subsequent  stages  may  well  result  in  addition,  deletion  or  amendment  to  the 
results  of  this  preliminary  work.  The  following  aspects  need  to  be  considered: 

(a)  Hardware  Environment.  This  includes  establishing  the  number  and  type  of 

processors  to  be  used,  the  size  and  type  of  each  main  storage  unit,  the  means  by 
which  hardware  modules  are  to  communicate  and  the  number  and  nature  of  the 
peripheral  devices  which  are  to  be  handled  by  the  system.  It  is  necessary  to 
complete  this  to  a  degree  which  is  adequate  to  support  any  hardware  interactions 
in  subsequent  stages  of  the  design,  and  to  identify  any  processing  or 
communication  constraints  which  may  affect  the  design  structure. 

(b)  Development  System,  This  includes  the  facilities  provided  by  the  programming 
and  project  support  environments  together  with  such  items  as  the  means  of 
prototyping  and  the  provision  of  test  harnesses.  All  these  facilities  are  central  to 
the  software  development  and  must  be  well  defined  early  on. 

(c)  Context(s).  This  involves  establishing  the  primitives  and  standard  support 

facilities  which  are  to  be  made  available  through  one  or  more  Mascot  context 

Interfaces 

(d)  Libraries  These  are  standard  support  facilities  which  are  to  be  created  outside 
the  context  and  made  available  through  library  Interfaces.  Both  libraries 
and  contexts  are  directly  supported  by  the  Mascot  design  representation 
facilities  their  definition  must  be  completed  in  time  to  support  the  programming 
stage  of  the  work 

The  method  includes  six  main  stages  as  follows: 

Stage  1  External  Requirements  and  Constraints 

Stage  2  :  Design  Proposal 

Stage  3  Network  Decomposition 

Stage  4  Element  Decomposition 

Stage  5  Program  Definition 

Stage  6  :  Test  System  Definition 

Each  of  these  will  be  illustrated  by  means  of  an  individual  diagram  derived  from  the  general  one  already 
presented.  The  seven  substages,  introduced  earlier  in  connection  with  the  general  decomposition 
model,  represent  specific  design  actions  related  to  the  decomposition  process  in  each  of  the  six  main 
stages.  Work  on  the  various  substages  of  any  particular  stage  will  proceed  in  parallel  and  need  not  be 
complete  before  work  is  started  on  further  stages  of  decomposition  Some  substages  are  not  present  in 
all  the  six  stages,  as  will  be  illustrated  by  means  of  the  individual  diagrams,  and  some  may  optionally  be 
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omitted  if  they  are  not  required  in  the  elaboration  of  a  particular  design  item.  An  arrow  leaving  a  box  in  any 
of  the  diagrams  represents  a  flow  of  information  to  a  further  stage  of  decomposition  (in  some  cases  within 
the  same  stage  of  the  method  such  as  where  a  network  is  decomposed  into  lower  level  networks). 


Stage  1  External  Requirements  and  Constraints 

This  stage  establishes  the  general  requirements  and  external  constraints.  The  substages  of  which  it  is 
comprised  are  illustrated  on  the  diagram  below  and  are  now  described  individually. 


2.1  2.1 


Stage  t 


Stage  1.1  (Requirements  Analysis)  involves  analysis  of  the  complete  system  (hardware  and 
software)  with  particular  emphasis  on  identification  of  the  software  system  requirements  and 
interactions.  Analysis  techniques  compatible  with  the  data  flow  and  network  principles  of  Mascot  (such 
as  CORE,  SSADM.  JSD  etc  )  are  particularly  relevant  during  this  stage 

Stage  1.2  (Hardware  System  Requirements)  describes  those  parts  of  the  system  whose 
functions  are  to  be  performed  by  hardware  units  They  are  not.  in  the  Mascot  method,  to  be  subjected 
to  further  decomposition  (box  12  possesses  no  output  arrow)  but  such  hardware  units  are  not  of 
course  precluded  from  containing  independent  items  of  software 

Stage  1.3  (Software  System  Requirements)  describes  what  the  software  has  to  do  in  terms  of 
transformations  of  data  and  responses  to  events  originating  outside  the  software  system. 
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Stage  1.4  (Software  System  Interactions)  describes  the  nature  and  purpose  of  each  implicit 
interaction  between  the  software  system  and  the  external  hardware  or  software  (including 
communication  with  an  operator) . 

Stage  1.5  (Overall  System  Test  Requirements)  describes  the  way  in  which  the  complete 
system  (hardware  and  software)  is  to  be  tested. 

Stage  1.6  (Overall  System  Test  Interactions)  identifies  particular  test  data,  expected  results 
and  the  operator  control  sequences  required  to  carry  out  the  tests  on  the  complete  system.  No  data  is 
carried  forward  to  later  stages  as  such  tests  are  applied  to  the  total  system  operating  in  its  natural 
environment. 

Stage  1  must  be  well  advanced  before  any  further  stages  of  the  development  work  are  started.  Although 
this  stage  does  not  produce  any  formal  Mascot  design  definitions  (apart  from  the  name  of  the  system 
template)  it  is  likely  to  involve  the  application  of  formal  techniques  for  requirements  analysis.  Notice  that 
this  stage  produces  the  requirements  and  device  interactions  for  a  Mascot  software  system  which  may 
itself  contain  embedded  hardware  components  (where  these  are  deemed  to  be  supportive  of  the 
software  design  rather  than  placing  constraints  upon  it  as  does  the  'non  negotiable  hardware'  discussed 
before  embarking  on  this  stage).  There  could  also  be  several  software  systems,  rather  than  just  one, 
interacting  through  intermediate  hardware.  The  overall  system  test  requirements  (stage  1.5)  and 
interactions  (stage  16)  are  not,  in  principle,  needed  until  the  end  of  the  development  when  hardware 
and  software  have  to  be  integrated;  however  stages  1.5  and  1.6  should  be  carried  out  as  early  as 
possible  since  they  provide  a  useful  measure  of  requirements  analysis  verification.  Indeed  in  all  stages 
which  generate  test  definitions,  the  fact  that  the  corresponding  tests  are  not  to  be  performed  until  later 
should  not  be  allowed  to  delay  work  on  their  definitions 


Stage  2  Design  Proposal 

This  stage  results  in  a  top  level  design  proposal  based  on  the  software  system  requirements  and 
interactions  identified  in  the  stage  1  Requirements  Analysis.  It  is  the  first  point  at  which  a  Mascot  design 
structure  emerges  The  corresponding  diagram  is  shown  below. 

Stage  2.1  (Software  System  Decomposition)  describes  the  top  level  application  software 
design  in  terms  of  a  Mascot  system 

Stage  2.2  (Hardware  Element  Requirements)  describes  what  each  of  the  items  of  supportive 
hardware  appearing  as  top  level  components  of  the  Mascot  system  has  to  do. 

Stage  2.3  (Software  Template  Requirements)  describes  the  template  requirements  for 
each  software  component  in  the  top  level  software  system  design. 
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3.1  3.1  5.1  3.1  4.1 

4.1  4.1 

5.1  5.1 

Stage  2 

Stage  2.4  (Interactions)  describes  the  nature  and  purpose  ot  the  internal  interactions  (paths) 
between  system  components 


Stage  2.5  (Mascot  System  Test  Requirements)  describes  the  way  in  which  the  Mascot 
system  is  to  be  tested.  No  data  is  carried  forward  to  later  stages  as  such  tests  are  applied  to  the  total 
software  system. 

Stage  2.6  (Mascot  System  Test  Interactions)  describes  the  particular  test  data,  expected 
results  and  the  operator  control  sequences  required  to  carry  out  the  Mascot  system  test. 


Stage  2.7  (Internal  Interaction  Elaboration)  identifies  the  definitions  (2.7.1),  access 
Interfaces  (2.7.2)  and  composite  access  interfaces  (2.7.3)  required  to  describe  the  paths 
between  system  components  and  the  types  of  the  data  which  flow  along  them. 
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No  further  stages  of  decomposition  can  be  started  until  at  least  the  system  template  has  achieved 
enrolled  status,  the  components  have  achieved  introduced  status,  and  the  access 
Interfaces  have  achieved  registered  status.  In  addition,  the  internal  paths  must  be  described  in 
terms  of  semantic  and  dynamic  properties  and  any  serial  ordering  constraints  which  apply  to  data  flow 
along  the  paths.  When  the  template  requirements  have  also  been  defined  then  this  is  sufficient  to 
allow  further  stage  3  or  stage  4  decomposition.  The  stage  5  program  design  of  an  element  or 
subelement  connected  by  an  Interface  identified  in  stage  2  cannot  be  started  until  the 
definitions  (2.7.1)  and  access  Interfaces  (2.7.2)  have  been  established.  Likewise  the  detail  of 
the  composite  access  Interfaces  (2.7 .3)  must  be  complete  before  a  composite  path  can  be 
expanded  in  a  subsequent  stage  3  subsystem  decomposition. 

The  result  of  the  initial  attempt,  at  this  stage,  to  identify  a  component  as  a  subsystem  (to  3.1),  or  an 
element  (to  5.1)  is  necessarily  provisional  The  ultimate  decision  as  to  whether  a  template  should 
be  further  decomposed  can  only  be  made  in  the  light  of  its  designer's  more  detailed  examination.  In 
the  case  of  an  element  this  examination  may  indicate  that  further  decomposition  is  desirable.  In 
these  circumstances  stage  5  is  abandonned  and  stage  3  or  stage  4  invoked,  as  appropriate.  It  is  also 
possible  that  subsequent  decomposition  fails  because  design  constraints  cannot  be  met.  In  this  case 
stage  2  must  be  repeated 

Stage  2  is  the  point  at  which  the  Mascot  method  starts  to  exert  its  influence  in  relating  software  design 
structure  to  external  requirements  and  constraints  identified  during  stage  1.  Ideally,  the  top  level  of 
software  design  expression  would  be  expected  to  contain  the  following  components. 

(a)  A  subsystem  (or  activity)  for  each  major  system  function. 

(b)  A  subsystem  (or  IDA)  for  every  major  system  data  requirement. 

(c)  A  subsystem  (or  server)  for  every  major  interaction  with  external  devices  or 
software  outside  the  system 

(d)  A  subsystem  for  every  systemwide  internal  communication  requirement. 

For  a  large  application  such  an  ideal  would  be  impractical,  resulting  in  an  unmanageable  number  of  top 
level  components  However,  these  components  would  be  expected  to  appear  during  the  first 
few  applications  of  Stage  3  (Network  Decomposition),  being  grouped  into  convenient  and  meaningful 
subsystems  at  higher  levels  As  a  rule  of  thumb,  the  number  of  components  at  any  one  level  of 
decomposition  should  be  not  more  than  twelve 

Stage  3  Network  Decomposition 

This  stage  is  concerned  with  the  progressive  decomposition  of  a  network  in  terms  of  lower  level 
networks  and  elements  and  is  illustrated  diagramatically  below.  It  is  applied  initially  to  each 
network  template  which  has  resulted  from  the  application  of  stage  2  (inputs  from  2.3.  2  4  and  2  7) 
and  to  any  network  templates  identified  as  necessary  for  testing  purposes  (input  from  6  3  in  stage 
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6  described  later).  Subsequently,  it  is  re-applied  to  every  lower  level  network  which  results  from  the 
decomposition  of  a  higher  level  one  (inputs  from  3.3,  3.4  and  3.7).  This  process  is  continued  until  the 
design  is  expressed  purely  in  terms  of  elements.  The  whole  stage  may  be  omitted  if  stage  2  has  not 
produced  any  components  which  are  networks. 

Stage  3.1  (Network  Decomposition)  describes  a  network  in  terms  of  its  components. 

Stage  3.2  (Hardware  Element  Requirements)  describes  the  characteristics  of  each  hardware 
element  identified  at  this  stage  of  the  design.  Hardware  components  at  this  and  lower  levels  can  be 
regarded  as  embedded  in  the  software  design. 

Stage  3.3  (Software  Template  Requirements)  describes  the  template  requirements  for 
each  component  of  the  network  design  which  is  to  be  implemented  by  a  Mascot  component. 


2.3 

3.3  2.4,  2.7 

6.3  3.4,  3.7 


6.1 

3.1 

3.1 

5.1 

3.1  4.1  6.1 

4.1 

4.1 

5  1 

5  1 

Stage  3 
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Stage  3.4  (Interactions)  describes  the  nature  and  purpose  of  the  internal  interactions  (paths) 
between  network  components. 


Stage  3.5  (Network  Test  Requirements)  describes  the  way  in  which  the  network  is  to  be 
tested  and  identities  a  test  system.. 

Stage  3.6  (Network  Test  Interactions)  describes  the  particular  test  data,  expected  results  and 
the  operator  control  sequences  required  to  test  the  network. 

Stage  3.7  (Internal  Interaction  Elaboration)  identifies  the  definitions  (3.7.1),  access 
interfaces  (3.7.2)  and  composite  access  interfaces  (3.7.3)  required  to  describe  the  internal 
paths  and  the  types  ot  the  data  which  flow  along  them. 

Stage  3  carries  on  the  network  decomposition  process  started  in  stage  2.  It  differs  from  stage  2  only  in 
that  it  is  totally  concerned  with  internal  design  decomposition  and  does  not  address  the  problem  of 
matching  the  software  design  to  the  external  environment.  This  results  in  two  significant  differences. 
First,  the  driving  input  for  stage  3  emerges  from  previous  Mascot  design  work  (stage  2,  stage  3  and  stage 
6  (where  the  decomposition  process  is  being  used  for  test  network  design)).  Second,  a  formally 
defined  test  system  is  required  to  test  a  stage  3  network;  hence  the  output  to  stage  6  (note  that  stage 
3,5  will  identify  the  name  of  the  test  system  for  subsequent  elaboration  in  stage  6). 

As  for  stage  2,  the  result  of  the  initial  attempt,  at  this  stage,  to  identify  a  component  as  a  subsystem 
(to  3.1),  or  an  element  (to  5.1)  is  necessarily  provisional  It  is  also  possible  that  subsequent 
decomposition  fails  because  design  constraints  cannot  be  met.  and  in  that  case  the  current  stage  must 
be  repeated 

Stage  4  Element  Decomposition 

Stage  4  is  concerned  with  the  decomposition  of  an  activity  in  terms  of  subelements  and,  if 
necessary,  of  subelements  in  terms  of  lower  level  subelements  IDAs  and  servers  are  precluded 
from  single  thread  decomposition  in  terms  of  subelements  This  form  of  activity  decomposition  is  an 
alternative  to  conventional  program  structuring  techniques  (for  example,  local  procedures,  blocks  etc  )  It 
has  the  advantage  of  producing  a  software  structure  visible  in  terms  of  Mascot  diagrams  and  of  increasing 
the  potential  for  re-usable  modules  by  the  linking  of  separately  compiled  units  It  allows  selective 
servicing  of  the  paths  which  are  connected  to  the  enclosing  element  or  subelement  and  generally 
improves  testability 

Stage  4  is  illustrated  diagramatically  below  Stage  4  is  applied  initially  to  each  element,  chosen  for 
decomposition,  which  has  resulted  from  the  application  of  stage  2  or  stage  3  (inputs  from  2  3.  2  4  ,  2  7. 
3  3,3  4  and  3  7)  and  to  any  similar  element  identified  as  necessary  for  testing  purposes  (input  from  6  3 
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in  stage  6  described  later).  Subsequently,  it  may  be  re-applied  to  lower  level  subelements  which  result 
from  the  decomposition  of  a  higher  level  element  or  subelement  (inputs  from  4.3,  4.4  and  4.7).  This 
process  is  continued  until  the  design  is  expressed  purely  in  terms  of  simple  subelements.  The  whole 
stage  may  be  omitted  if  stages  2,  3  and  6  do  not  produce  any  activities  which  need  to  be  decomposed. 

Stage  4.1  (Element/Subelement  Decomposition)  describes  an  element  or  subelement 
in  terms  of  subelements. 


Stage  4.3  (Template  Requirements)  describes  the  template  requirements  for  each 
component. 


Stage  4.4  (Interactions)  describes  the  nature  and  purpose  of  the  internal  interactions,  (that  is 


links)  between  components 


4  1  4  1  5  1  4.1  6  1 

5.1  5  1 


Stage  4 
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Stage  4.5  (Element/Subelement  Test  Requirements)  describes  the  way  in  which  the 
element  or  subelement  is  to  be  tested 

Stage  4.6  (Element/Subelement  Test  Interactions)  describes  the  particular  test  data,  expected 
results  and  the  operator  control  sequences  required  to  test  the  element  or  subelement. 

Stage  4.7  (Interaction  Elaboration)  identifies  the  definitions  (4.7.1)  and  subroot  Interfaces 

(4.7.2)  required  to  describe  the  internal  links  and  the  types  of  the  data  which  flow  along  them. 


Stage  5  Program  Definition 

Stage  5  is  the  programming  stage  during  which  the  source  text  for  each  simple  module  is  produced 
Its  diagrammatic  representation  is: 


6.1 


Stage  5 


6.1 


Simple  templates,  produced  in  any  of  the  previous  3  stages,  form  the  input  to  stage  5  (from  2  3.  2.4. 
2  7.  3  3.  3  4.  3.7,  4  3.4  4  and  4  7)  Further  simple  templates,  needed  for  testing  purposes,  may  be 
derived  from  stage  6  (6  3)  which  is  described  later 

Stage  5.1  (Program  Decomposition)  describes  the  design  of  simple  templates  in  terms  of 
aigonthms  and  data  structures 

Stage  5.5  (Simple  Template  Test  Requirements)  describes  the  way  in  which  the  simple 
template  is  to  be  tested 

Stage  5.6  (Simple  Template  Test  Interactions)  describes  the  particular  test  data,  expected 
results  and  the  operator  control  sequences  required  to  test  thsimple  template 
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If  during  the  program  decompostion  it  is  found  that  further  structural  decomposition  would  be  desirable 
then  stage  5  may  be  abandonned  and  stage  3  or  stage  4  invoked,  as  appropriate  Thus  stage  5 
terminates  the  primary  design  process  as  far  as  Mascot  is  concerned,  although  it  may  result  in  a 
requirement  for  supporting  work  on  test  system  design.  Any  conventional  technique  for  program 
design  may  be  used  within  this  stage  provided  it  is  used  consistently.  However,  its  use  should  be 
confined  to  the  expression  of  algorithms  and  data  structures  within  a  single  module;  decomposition  in 
terms  of  separately  compiled  modules  is  regarded  as  a  stage  4  design  action  and  should  use  the 
appropriate  Mascot  design  feature.  If  the  functional  requirements  cannot  be  met  within  the  constraints 
then  the  previous  stage  must  be  re-invoked. 


Stage  6  Test  System  Definition 

Stage  6  is  concerned  with  the  integration  and  testing  of  application  software.  Its  diagrammatic 
representation  is 


3  5  3  6 

4  5  4  6 

5  5  5.6 


I 


3  1 
•1  1 

5  i  Stage  6 

Input  to  stage  6  consists  of  the  test  requirements  and  interactions  for  networks, 
elements/subelements  and  simple  templates,  respectively,  identified  in  stage  3.  stage  4  and 
stage  5  (from  3  5,  3  6.  4.5  4  6.  5  5  and  5  6) 

Stage  6.1  (Test  System  Decomposition)  describes  the  structure  ot  the  test  system 


Stage  6.3  (Test  Template  Requirement)  describes  what  each  test  template,  required  to 
create  acomponent  specifically  identified  for  test  purposes,  has  to  do 
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Stage  6  is  concerned  with  the  first  level  of  test  system  decomposition.  The  requirements  for 
networks,  element/subelements  and  simple  templates  identified  in  stage  6.3  are  fed  back  to 
stages  3,  4  and  5,  respectively  for  further  decomposition  as  necessary.  Notice  that  if  a  standard  harness 
can  be  used  for  testing,  and  if  no  special  test  components  are  required,  then  stage  6.3  may  be  omitted 
Stage  6  designs  will  work  entirely  in  terms  of  the  substage  6  test  interactions  and  substage  4/substage  7 
operational  interactions  derived  from  the  previous  stages. 

Status  Progression 

Throughout  all  six  stages  of  the  development  the  Mascot  design  notation  is  used  to  record  the  product  of 
the  design  process,  and  the  status  progression  facilities  are  used  to  record  progress  and  to  control  the 
use  to  which  the  various  parts  of  the  design  definition  may  be  put.  Mascot  formality  is  limited  to  these 
aspects  but  any  other  formal  techniques  for  function  or  data  flow  definition  may  be  used  in  conjunction 
with  Mascot  with  direct  reference  to  templates,  components,  Interfaces,  paths  or  links  in  the 
design  structure. 
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5.2  DOCUMENTATION 


Introduction 

The  use  of  the  Mascot  method  should  be  supported  by  a  suitably  structured  approach  to  the 
documentation  requirement  at  each  stage  in  development.  Well-structured  documentation  will  support 
the  system  throughout  its  life-cycle  by  relating  system  design  to  requirements  and  external  constraints, 
allowing  descriptions  to  be  created  and  maintained  in  a  recognisable  framework  and  facilitating  access  to 
this  information  by  the  wide  variety  of  personnel  who  need  it. 

It  is  not  intended  in  this  Handbook  to  provide  prescriptive  techniques  or  standards  for  documentation, 
because  there  is  a  wide  range  of  diverse  documentation  standards  to  which  Mascot  systems  will  be 
required  to  conform.  However,  it  should  be  recognised  that  software  documentation  does  not  exist  in  a 
vacuum  and  must  be  part  of  the  overall  documentation  strategy.  The  documentation  structure  for  a 
medium-to-large  project  is  inevitably  large  and  complex  and  involves  many  inter-dependencies.  It  is 
essential  that  this  structure  is  planned  at  the  outset  of  a  project  and  used  by  the  development  team  as  the 
project  progresses.  Used  correctly,  a  recognised  structure  will  reduce  duplication/overlap  in 
documentation,  facilitate  access  to  information,  allow  consistency  checking  and  localise  the  effects  of 
software  amendments  on  documentation 

The  following  points  should  be  taken  into  account  when  planning  the  documentation  structure: 

The  Mascot  method  assists  in  re-usability  of  software,  and  the  re-usability  of 
associated  documentation  is  an  important  consideration.  As  far  as  possible, 
information  which  is  project-specific  should  be  isolated,  in  documentation  terms, 
from  re-usable  information. 

A  single  template  can  be  used  to  create  several  components  in  a  typical  Mascot 
application,  and  so  information  concerning  the  creation  of  components  should  be 
separated  from  the  formal  software  descriptions  and  documentation  of  the 

template. 

The  development  and  target  environments  for  emoedded  software,  for  example 
tools  and  hardware  configurations,  are  liable  to  change  in  the  potentially  long  life 
(say,  20  years)  of  a  typical  Mascot  application.  The  documentation  should  lend 
itself  to  such  amendment  by  separating  information  describing  the  environment 
from  formal  software  description. 

The  primary  aim  of  documentation  is  to  aid  comprehension.  Without  compromising  this  aim,  it  is  possible 
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to  use  the  Mascot  module  classes  as  a  framework  for  re-usable  documentation.  Wherever  feasable, 
description  should  be  restricted  to  the  scope  of  the  object  being  documented.  For  example,  the 
documentation  of  a  template  module  should  avoid  reference  to  the  functionality  of  elements  beyond 
the  Interfaces  which  it  provides  and  requires. 

The  result  of  this  approach  is  documentation  which  is  both  abstract  and  localised  in  nature.  Although  this 
achieves  the  goal  of  re-usability,  there  is  a  danger  that  over-zealous  abstraction  may  lead  to 
documentation  which  is  disjoint,  making  it  difficult  to  comprehend  overall  functionality  without  reference 
to  numerous  items  of  documentation.  It  can  be  seen  that  the  goals  of  comprehensibility  and  re-usability 
are  not  always  compatible. 

As  a  general  rule,  the  characteristics  of  a  description  should  be  similar  to  those  of  the  object  being 
described.  If  a  module  is  created  for  widespread  general  use  then  re-usability  of  documentation  is  of 
paramount  importance.  If  a  module  has  many  dependencies  on  the  characteristics  of  external  objects 
(say,  for  efficiency  reasons),  then  the  requirements  of  comprehensibility  must  take  precedence.  Most 
software  is  a  compromise  between  the  desire  for  re-usability  and  the  needs  of  a  specific  application,  and 
so  engineering  judgement  is  required  when  determining  what  form  of  documentation  should  be  used  for 
individual  modules  and  module  classes 


By  way  of  illustration  of  the  above,  consider  the  requirements  for  the  documentation  of  an  individual 
template.  The  documentation  must  describe  the  functionality  of  the  template  and  the  Interfaces 
which  it  provides  and  requires  (the  specification  documentation).  If  the  template  is  composite,  the 
documentation  must  identify  the  internal  structure  of  the  template  in  terms  of  components  and  their 
inter-connectivity  (the  implementation  documentation). 

In  all  cases,  the  descriptive  content  of  the  specification  documentation  must  be  detailed,  complete  and 
unambiguous.  This  is  the  lowest  level  in  the  hierarchy  at  which  this  documentation  will  be  presented 

The  more  difficult  aspect  of  template  documentation  concerns  the  level  of  detail  ot  the  implementation 
documentation.  Clearly,  the  rationale  behind  the  decomposition  within  the  template  must  be  presented 
in  full.  The  level  of  description  given  for  the  components  and  their  inter-connectivity  must  be  carefully 
considered. 

It  would  be  possible  to  identify  the  components  and  internal  Interfaces  by  name  only,  and  refer  the 
reader  to  lower  level  modules  whose  specification  documentation  will  provide  the  information  on  the 
functionality  of  individual  items.  Whilst  this  would  meet  the  goal  of  re-usability,  such  an  approach  would 
tend  to  be  abstract  to  the  point  of  obscurity.  Alternatively,  if  detailed  descriptions  of  the  means  by  which 
internal  components  achieve  their  functions  are  provided,  then  this  leads  to  undesirable  duplication 
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within  the  documentation  hierarchy 


Experience  indicates  that  the  preferred  approach  in  most  circumstances  is  to  describe  in  full  how  the 
template  achieves  its  required  function,  and  to  provide  brief  descriptions  of  the  components  and 
their  inter-connectivity,  referring  the  reader  to  lower  levels  of  the  documentation  hierarchy  if  more  detail 
on  a  particular  component  is  required  This  approach  allows  a  reader  to  assimilate  sufficient  concise 
information  to  understand  how  the  internal  elements  of  a  template  achieve  the  necessary  functionality 
of  that  template,  without  unnecessarily  duplicating  the  specification  documentation  of  the  lower  level 
modules 

The  Mascot  method  encourages  isolation  of  information  by  recognising  the  independent  nature  of  active 
and  passive  elements,  Interfaces,  definitions,  libraries,  etc  As  far  as  possible,  without  losing  sight 
of  the  need  for  comprehensibility,  the  documentation  strategy  should  follow  the  same  approach. 

Control  of  Documentation 

In  a  project  of  any  reasonable  size,  a  large  quantity  of  documentation  must  be  administered  and 
controlled.  The  documentation  is  the  primary  method  of  communicating  information  about  the  structure 
and  status  of  the  system  under  development  to  all  interested  parties  in  the  project.  As  the  system  is 
developed  and  amended,  so,  too,  is  its  associated  documentation  It  is  clearly  necessary  for  the 
documentation  to  be  in  step  with  the  system  it  describes  at  all  stages.  Generally,  this  can  be  achieved  for 
documentation  in  the  form  of  in-line  comment,  because  this  is  retained  within  the  module  it  describes 
and  is  subject  to  the  configuration  management  and  quality  control  procedures  applied  to  individual 
modules 

Some  project  documentation  is  not  directly  related  to  a  specific  class  of  Mascot  module  (for  example, 
requirements,  quality  reports,  design  rationale  documents)  Nonetheless,  it  is  strongly  recommended 
that  all  project  documentation  is  held  in  a  machine-readable  form  under  the  same  configuration 
management  database  as  that  used  to  administer  software  development.  Wherever  possible, 
documentation  relating  to  a  specific  module  should  be  held  as  part  of  that  module  Although  this  does 
not  guarantee  that  documentation  will  be  updated  in  line  with  the  software,  its  proximity  will  encourage 
good  practice  and  ease  consistency  checking 

The  configuration  management  database  can  be  used  to  create  and  maintain  a  knowledge  of  the 
dependencies  between  documents  and  modules  When  a  module  or  document  is  updated,  the 
dependency  relationships  can  be  used  to  identify  other  modules  or  documents  which  may  be  affected 
by  the  change.  Status  progression  is  the  minimum  facility  provided  by  the  Mascot  database,  and  will 
generally  deal  with  identifiable  Mascot  module  classes.  In  some  cases,  it  may  be  possible  to  provide 
similar  mechanisms  for  documents. 
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If,  for  some  reason,  documentation  is  not  held  in  a  machine -readable  form  and  related  in  a  controlled 
fashion  to  the  system  being  described,  procedures  must  be  adapted  to  provide  confidence  that 
documentation  and  software  will  proceed  through  development  in  a  consistent  manner.  Configuration 
management  and  quality  assurance  procedures  must  be  applied  to  the  documentation,  even  if  only  by 
manual  means. 

Access  to  Documentation 

The  exisistence  of  documentation  does  not  in  itself  guarantee  its  accessibility.  The  sheer  extent  of 
documentation  can  make  it  difficult  to  identify  and  retrieve  precisely  that  part  of  the  documentation  which 
is  necessary  to  understand  a  particular  facet  of  the  system  and  carry  out  an  item  of  work.  The  problem  of 
collating  and  constraining  relevant  information  is  not  new,  however,  and  it  is  important  to  provide  such  a 
facility  if  work  is  to  be  carried  out  efficiently. 

The  publication  of,  and  adherence  to,  the  overall  project  documentation  structure  will  assist  in  the 
identification  of  relevant  information.  However,  in  many  cases  the  information  needed  to  build  a  clear 
picture  of  the  context  in  which  a  piece  of  work  is  to  be  carried  out  will  be  distributed  through  many 
modules  These  modules  will  also  contain  material  which  is  extraneous  to  the  individual's  requirement. 
There  is  a  strong  case,  when  employing  Mascot,  to  consider  the  use  of  a  documentation  tool  which  will 
assimilate  the  specification  documentation  and  implementation  documentation  of  a  number  of  modules 
into  a  single  document.  This  will  allow  a  reader  more  easily  to  comprehend  the  role  of  a  template  in  the 
overall  system.  The  existence  of  such  a  tool  may  reduce  the  temptation  to  duplicate  documentation  at 
different  levels  of  the  document  hierarchy. 

The  tool  would  be  achievable  by  identifying  (say,  by  a  keyword  mechanism)  the  specification 
documentation  and  the  implementation  documentation  within  each  module.  In  order  to  see  more  clearly 
the  role  of,  say,  a  subsystem,  a  user  potentially  could  gather  together  into  a  single  document: 

(a)  the  implementation  documentation  of  the  enclosing  subsystem, 

(b)  the  specification  and  implementation  documentation  of  the  subsystem  under 
scrutiny  and 

(c)  the  specification  documentation  of  the  components  and  Interfaces  which 
comprise  the  subsystem 

using  the  relationships  between  the  modules  and  the  documents  established  by  means  of  the 
configuration  management  database. 
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Purpose  of  Documentation 


There  are  two  major  categories  of  documentation  according  to  its  prime  purpose:  documentation  of  the 
project  and  documentation  of  the  resultant  system.  These  are  now  discussed  in  turn. 

Documentation  of  the  Project 

Documentation  is  created  and  amended  throughout  the  system  life-cycle  in  order  to  capture  and  express 
the  current  status  as  development  proceeds.  However,  it  is  not  sufficient  merely  to  maintain  current 
status  information.  The  development  of  documentation  through  the  system  life-cycle  reflects  the  design 
decisions  and  rationale  which  invariably  affect  and  shape  the  path  to  the  final  system.  It  is  important, 
therefore,  to  capture  and  maintain  the  documentation  as  it  existed  at  various  major  points  in  the  system's 
evolution.  If  an  'audit  trail'  of  this  form  can  be  created,  it  will  allow  analysis  of  the  design  process  which  led 
to  the  complete  system  Further,  if  this  information  can  be  allied  to  quality  records,  modification  records, 
etc.,  then  analysis  can  prove  extremely  valuable  to  future  projects  and  can  be  exceptionally  useful  during 
maintenance  and  support  of  the  system. 

In  many  cases,  collation  of  the  information  required  for  this  analysis  is  difficult  as  it  exists  in  different  forms 
(some  as  part  of  modules  in  the  host  system,  paper  records  held  by  the  quality  assurance  department, 
etc  ),  and  results  in  an  incomplete  and  disjoint  record.  The  use  of  a  suitable  configuration  management 
tool  (possibly  allied  to  the  Mascot  database)  incorporating  design  change  control  and  quality  assurance 
recording  mechanisms  will  assist  in  collating  information  in  a  manner  which  is  coherent  and  provides  a 
convenient  form  of  reference 

Documentation  of  the  System 

The  descriptive  information  required  to  support  the  resultant  system  incorporates  not  only  the 
documentation  of  the  templates  and  associated  modules  used  to  create  the  network 
components,  but  also  the  documentation  of  the  testing  mechanisms  used  to  verify  functionality.  The 
relationship  between  documentation  of  these  areas  requires  careful  organisation  There  is  not 
necessarily  a  one-to-one  correspondence  between  test  systems  and  templates.  However,  there 
must  be  a  mechanism  for  relating  the  template  documents  to  the  test  system  documentation, 
preferably  one  which  does  not  adversely  affect  the  re-useability  of  the  documents 

The  documentation  of  a  template  may  refer  to  a  test  system  created  to  test  that  template.  It  should 
not  refer  to  test  systems  which  test  sub  networks  in  which  the  template  is  used  Test  system 
documentation  should  refer  to  all  components/templates  in  the  sub  network  under  test  The  result 
is  that  the  test  documentation  structure  reflects  the  network  structure  and  the  documentation  of  the 
sub-networks  should  refer  to  the  test  systems  used  to  verify  functionality. 
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General  Documentation  Requirements  for  Module  Classes 


There  are  generalised  requirements  for  the  documentation  of  all  modules  in  a  Mascot  system,  as 
outlined  below. 

The  following  categories  should  be  considered  in  the  documentation  of  all  modules,  although  some 
categories  may  not  be  applicable  directly  to  a  particular  module  class. 

Language  dependencies 
Environment  dependencies 
Machine  dependencies 

Code  characteristics  (eg  conditional  compilation,  assembler  inserts) 

Test  status 

Quality  assurance  status 
Test  mechanism 

For  each  module  under  development,  the  following  must  be  available,  either  embedded  in 
documentation  or  controlled  by  tools: 


Version  number 
Modification  audit  trail 
Mascot  database  status 

All  modules  must  refer  to,  or  include  in-line,  the  requirement  which  they  are  designed  to  meet 
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5.3  SYSTEM  TESTING 


Introduction 

During  the  design  and  development  stages  of  a  project  there  are  several  techniques  which  have 
traditionally  been  used  to  establish  confidence  in  the  software  being  created  and  to  demonstrate  that  it 
meets  its  requirements.  These  include  formal  techniques  for  proving  correctness  lesign  reviews,  in 
which,  among  other  activities  (see  Section  5.1),  program  source  text  is  subjected  to  the  collective 
scrutiny  of  the  project  team,  and  testing,  in  which  the  behaviour  of  the  corresponding  executable  code  is 
systematically  exercised  through  the  use  of  test  data.  Testing  is,  and  is  likely  to  remain,  the  most  widely 
used  of  these  techniques  This  is  partly  because  of  its  wider  scope  including  ,  as  it  does,  the  effects  of 
production  tools,  operating  system,  hardware  and  external  environment,  and  partly  on  account  of  the 
greater  psychological  assurance  which  it  engenders  ('seeing  is  believing').  It  is  also,  at  the  present  time, 
the  only  practical  method 

Mascot,  in  common  with  other  software  development  methods,  contains  a  graphical  form  of  design 
representation  which  can  be  exploited  to  advantage  in  carrying  out  a  design  review.  It  is  in  the  sphere  of 
testing,  however,  that  Mascot  provides  significantly  greater  assistance  than  most  other  methods.  In 
particular  the  modularity  scheme  of  Mascot,  together  with  the  unique  template-component  model, 
constitutes  a  powerful  support  mechanism  for  testing.  In  addition,  the  ability  to  supply  a  separate  system 
template  for  each  test  network  provides  a  sound  basis  for  the  configuration  management  of  testing 
The  template/component  model  makes  it  possible  to  create  test  systems  which  can  co-exist  with 

the  application  systems  This  greatly  simplifies  the  handling  of  regression  testing  during  maintenance 

« 

Provided  that  suitable  run-time  environments  are  available,  and  that  the  application  templates  contain 
no  hardware  specific  features,  the  test  networks  may  be  executed  on  either  host  or  target  systems  (  see 
Section  3.3). 

In  this  section  the  general  considerations  for  the  testing  of  Mascot  systems  are  discussed  and  a  specific 
testing  strategy  is  proposed 

General  Considerations 

The  testing  of  any  substantial  piece  of  software,  from  a  large  sequential  program  to  a  full  blown  system 
involving  concurrency  on  a  large  scale,  needs  to  be  carried  out  in  a  modular  fashion.  There  are  two  widely 
recognised  approaches  to  this  known  respectively  as  top-down  and  bottom-up. 

In  the  top-down  approach  the  highest  level  unit  is  produced  first  and  'stubs'  are  created  to  replace  the 
units  at  the  next  lower  level  These  stubs  are  sections  of  program  which  normally  perform  some  simple 
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actions  such  as  signalling  the  fact  that  they  have  been  evoked  and  reporting  the  values  ot  any  input  data 
with  which  they  have  been  supplied.  In  some  cases,  however,  a  stub  may  partially  emulate  the  actions  of 
the  unit  in  whose  place  it  stands.  Testing  involves  examining  the  pattern  of  invocation  of  the  lower  level 
entities.  Stubs  are  then  progressively  replaced  by  the  corresponding  application  units  accompanied, 
where  necessary,  by  a  further  level  of  stubs.  The  great  merit  of  this  approach  is  that  testing  and 
integration  proceeds  in  a  series  of  roughly  equal  steps.  The  last  step  is  no  more  significant  in  itself  than 
any  of  the  others  and  no  more  likely  to  reveal  any  fundamental  defect.  Also  application  units  can  be 
constructed  using  their  stubs  as  a  starting  point. 

In  the  bottom-up  approach  it  is  the  lowest  level  units  which  are  produced  first.  Specially  written  drivers  are 
then  used  to  test  them,  first  individually,  and  then  in  larger  and  larger  groups  until  the  entire  application 
has  been  built.  New  drivers  are  needed  at  each  stage  and  discarded  after  use.  The  final  step  in  this 
process  is  highly  significant  as  it  may  show  that  the  overall  structure  is  incorrect.  Despite  these 
disadvantages  the  bottom-up  approach  is  widely  used  in  practice  and  is  considered  by  many 
programmers  to  be  the  natural  way  to  test  software. 

While  a  strong  case  can  be  made  out,  at  least  in  theory,  for  application  of  the  top-down  approach  to 
testing  sequential  programs,  it  is  more  difficult  to  see  how  to  apply  it  to  the  networks  of  concurrent 
processes  required  to  solve  real-time  problems.  In  Mascot,  therefore,  its  application  is  likely  to  be  limited 
to  the  testing  of  the  implementation  details  of  simple  activities,  roots,  subroots  and  libraries.  The 
testing  of  Mascot  networks  is  likely  to  be  carried  out  bottom-up 

In  devising  a  general  strategy  for  testing  Mascot  modules  it  is  necessary  to  cater  for  three  groups: 
specifications,  simple  templates  and  composite  templates  Since  specifications  have  no 
direct  realisation  in  the  executable  software  there  is  no  direct  testing  associated  with  them 

Simple  templates  constitute  the  algorithmic  building  blocks  of  the  system,  and  the  testing  of  these 
templates  is  primarily  aimed  at  detecting  algorithmic  and  programming  errors  For  this  purpose  a  mixture 
of  'black  box'  test  data,  based  on  the  design  specification,  and  'white  box'  test  data  based  on  the  actual 
design  is  appropriate  At  the  very  least  these  latter  data  should  exercise  every  sub-condition  of  each 
conditional  expression  so  as  to  ensure  that  every  statement  in  the  program  is  executed  at  least  once 

Composite  templates  are  groupings  of  components  derived  from  simple  and  composite 
templates  The  primary  aim  in  testing  them  is  to  detect  errors  of  communication  between  the 
components  and  to  verify  the  real-time  behaviour 


An  Example  Testing  Strategy 


This  section  describes  a  specific  testing  strategy  developed  from  one  that  has  been  used  successfully  in 
several  projects  which  employed  an  earlier  version  of  Mascot  It  supports  testing  of  both  simple  and 
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composite  templates  and  serves  here  as  an  example  of  recommended  practice.  It  was  designed  to 
meet  the  following  major  requirements  : 

1 .  The  test  strategy  and  supporting  tools  should  support  both  formal  (that  is  Quality  Assurance)  and 
informal  (that  is  development)  testing  in  a  consistent  and  reproducible  manner. 

2.  The  production  and  maintenance  of  the  test  data  should  require  a  minimum  of  special  tools. 

3.  The  tools  should  support  interactive  diagnosis  with  data  entered  from  the  terminal  and  results 
displayed  at  the  terminal 

4.  To  facilitate  regression  testing,  the  performance  of  fests  and  the  interpretation  of  results  should 
require  a  minimum  of  manual  intervention. 

5.  Since  in  many  cases  the  target  hardware  does  not  become  available  until  late  in  the  software 
production  cycle,  it  should  be  possible  to  perform  the  majority  of  the  testing  on  the  host  computer. 

The  strategy  is  based  on  the  concept  of  a  test  script  containing,  in  a  machine-readable  form,  the 
directives  necessary  to  initialise  a  test  system,  data  which  are  to  be  presented  to  the  unit  under  test  and 
results  which  are  to  be  expected  if  the  unit  is  correct.  A  test  script  is  prepared  in  a  textual  form  which  may 
be  manipulated  by  means  of  standard  text  editors.  If  used  directly  in  this  form,  execution  time  is  taken  up, 
during  the  test,  in  performing  the  necessary  type  conversions.  An  alternative  is  to  employ  special  tools  to 
convert  the  script,  separately,  to  a  binary  form  but  this  was  not  adopted  in  view  of  general  requirement  3 
above 

A  test  script  may  be  interpreted  by  a  standard  network  of  test-administering  components,  supported 
by  application  specific  type  conversion  components.  These  two  sets  of  components,  together  with 
the  unit  under  test,  form  a  test  system 

The  precise  nature  of  the  conversion  components  is  dictated  by  the  communication  requirements  of 
the  unit  under  test  For  testing  IDAs,  servers  and  libraries  an  activity  is  the  natural  choice  since  such 
components  need  to  be  driven.  A  root  can  most  readily  be  used  to  convert  data  for  a  subroot  which 
is  under  test,  while  for  testing  roots  and  activities  an  IDA  may  be  chosen  as  the  conversion 

component 

The  role  of  the  standard  test  components  is  to  provide  textual  information,  from  a  test  script,  to  the 
conversion  components.  The  latter  convert  this  information  to  a  suitable  form  and  transmit  it  to  the  unit 
under  test  This  process  is  reversed  in  handling  the  responses  These  are  taken  from  the  unit  under  test 
by  the  conversion  components,  transformed  into  text  and  passed  to  the  standard  test  components 
which  generate  the  results. 
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Thus,  each  conversion  component  refers,  in  general,  to  three  Interfaces  describing,  respectively, 
text  input,  text  output  and  communication  with  the  unit  under  test.  The  textual  interfaces  are  usually 
ports  which  may  be  connected  to  windows  of  the  standard  test  components.  One  or  other  of  the 
text  Interfaces  may  be  omitted  in  some  cases.  The  Interface  to  the  unit  under  test  may  be  an  access 
Interface,  a  subroot  Interface  or  a  library  Interface  The  Mascot  monitoring  facilities  may  be  used, 
dunng  testing,  to  provide  evidence  of  completness. 

An  example  of  a  test  network,  in  which  the  conversion  components  are  activities,  is  shown  on  the 
following  page  Subsystems  have  been  shaded  in  this  diagram  in  order  to  improve  readability. 

Operation  of  the  Example  Test  Network 

Existing  operating  facilities  are  used  to  assign  the  input  and  output  (files)  to  the  servers  lnput_server 
and  output^server  When  the  system  is  STARTed,  each  of  the  conversion  activities  oeclares  its 
identity  to  the  IDA  text  and  receives  in  return  a  unique  key  The  relevant  arrowheads  on  the  network 
connections  through  which  this  initialising  transaction  takes  place  are  omitted  from  the  diagram  so  as  to 
avoid  unnecessary  complication  Subsequently,  messages  directed  to  a  particular  conversion  activity 
can  be  obtained  by  the  activity,  from  the  IDA,  by  quoting  the  appropnate  identifying  key 

The  command  interpreter  activity,  ci ,  reads  a  command  line  from  input_server  and  copies  it  directly 
to  output_server  The  purpose  of  logging  the  input  text  together  with  the  results  of  the  test  in  this  way 
is  to  allow  the  sequence  of  events  during  the  test  to  be  deduced  from  inspection  of  the  output  file.  This 
has  been  found  to  work  well  in  practice  even  when  quite  large  portions  of  the  final  network  are  being 
tested 

The  input  line  is  then  examined  by  the  command  interpreter  to  see  if  it  contains  a  command  which  can 
immediately  be  executed  and.  if  so.  the  required  action  is  performed  Commands  whose  execution  may 
be  initiated  by  the  command  interpreter  include  Execution  Control  commands,  Monitoring  Control 
commmands  and  special  commands  to.  for  example,  control  the  timing  of  events  in  the  network  If  the 
command  line  cannot  be  dealt  with  in  this  way.  it  is  passed  to  IDA  text  where  it  becomes  available  to  the 
conversion  activity  whose  identity  it  contains  An  error  message  is  generated  if  the  line  contains  no 
recognisable  identity 

The  unit  under  test  in  this  example  may  be  any  passive  network  fragment,  that  is  one  possessing  only 
windows  on  its  boundary  Messages  received  by  conversion  activities  from  text  are  converted  to  a 
suitable  form  and  passed  to  the  appropriate  access  mechanism  of  the  unit  under  test  Any  response  is 
made  available  at  another  window  for  use  by  a  converter  which  processes  it  for  output 

Thus,  to  handle  output,  the  converters  call  the  appropnate  access  mechanism,  translate  the  response 
into  textual  form  and  pass  the  result  to  output_server  Under  some  circumstances  it  is  necessary  for 
output  conversion  to  be  controlled  from  the  test  script  Hence  the  connection  of  all  converters  in  the 
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diagram  to  the  IDA  text .  The  need  for  this  most  commonly  occurs  when  testing  a  pool  where  the  input 
line  may  contain  a  command  to  read  the  pool  contents.  However,  another  possibility  is  that  the  input  line 
contains  a  copy  of  the  expected  results  which  the  converter  handling  output  can  compare  with  the  actual 
results  and  so  signal  whether  the  test  has  been  passed  or  failed. 
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DESIGN  REPRESENTATION  LANGUAGE  SYN TAX 

The  syntax  of  the  Mascot  design  representation  language  is  mclad-d  hm-  for  reference  purposes  It  is 
presented  in  two  equivalent  forms.  A  set  of  syntax  diagrams ,  as  used  for  description  throughout  the  body 
of  the  Handbook,  appears  first  together  with  an  index  These  diagrams  follow  the  conventions 
established  by  Wirth  in  connection  with  the  Pascal  programming  language  All  valid  constructs  may  be 
generated  by  tracing  all  possible  paths  through  each  diagram,  as  indicated  by  the  arrow  heads  from  the, 
top  left  until  the  path  terminates  on  the  right.  Loops  may  be  repeated  as  often  as  required  At  each  box  a 
basic  symbol  of  the  language  is  generated.  Where  the  box  has  rounded  comets  or  is  circular,  the  symbol 
is  literally  that  contained  in  the  box.  This  has  been  further  emphasi  m-:J  ,n  it  o  tenner  case  by  the  addition 
of  background  shading.  A  rectangular  box  is  a  reference  to  another  syntax  diagram 

The  diagrams  are  complete,  in  Mascot  terms,  in  that  they  mciud--  a"  ”,  ■  mandatory  features  They  are 

incomplete  in  the  sense  that  they  contain  a  number  of  undeleted  ,mt. .  ■  d.d.nition  is  dependent 

on  the  choice  of  implementation  language.  Such  undefined  s  m  be  am  -  :.  af-,-d  toy  nicam  of  a  near 
the  top  righthand  corner  of  the  syntax  box  A  second  group  of  sym'  *  *  *•  r  •,*.!-•  n  no  g-'m  r-g  d.agrnm  is 
included,  are  marked  with  a  '$’  These  are  all  identifiers,  they  a  nr-  .v  imd-  •  a  vin.>i,  of  names  so  as  to 
incorporate  some  semantic  information  Where  a  syntax  b~>  ■  -  ••••  :  •*,.»  corresponding 

definition  diagram  appears  on  page  'n'  of  the  appendix  Where  a.  r.  .  .  men- e-i  ,t  represents  a  svmbol 
which  is  defined  on  the  same  page  on  which  it  is  used. 

The  design  language  syntax  is  then  presented  in  a  metabmgu  n-‘ n  \  <-.r 

form  it  is  made  specific  to  the  use  of  Pascal  as.  the  mop  er;,'  ■  •  •  .  •  . ,  ---  ■•■  r  -.-me:. 

are  explicitly  connected  to  the  Pascal  syntax  del.mtion  i  a.-  ;•  ;  -mm  cm  presentation  i; 

such  as  to  facilitate  reference  to  the  subsection,  in  the  bom.  o  ►  each  construct  is 

discussed.  It  is  followed  by  an  alphabetically  ordered  hr:  .:  ■  .-crams  appropriate 

subsection  references.  It  should  be  noted  that  for  B  N  not  a?  -r  as ...  .  ■  :  v  -•  equiva'ent  syntax 
diagrams,  it  has  been  necessary  to  introduce  additional  syntactic  catcgomm  a  •••  :■  cafogcry  names  which 
in  the  diagrams  have  been  shortened  so  as  to  save  space  am  m-  •  ••  •.  ”  3  N  term  ?•;>•  example 

'acc_int_spec_part' becomes  access  interface  specifioat  c  r-  y  m 
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Index  to  Syntax  Diagrams 

Syntax  Diagrams 

Bachus  -  Naur  Form  of  Syntax 


Syntax  Index  to  Handbook 


A-3 

A-7 

A-28 

A-37 
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DIAGRAMMATIC  FORM  OF  SYNTAX 


Index 

syntax  element 

access_equivalence_list 

access  interface 

acc_int_array__descrip 

acc_int_detail_part 

acc  _i  nt_name_part 

acc_int_ref_list 

acc  _i  nt_spec_part 

act_component_class 

act_component__part 

act_connection_spec 

act_im  ppart 

activity 

act_name_part 

act_spec_part 

comp_acc_int_spec_part 

com  p_act  _i  m  p_p  a  rt 

component_c!ass 

component_part 

connection_spec 

const_spec_list 


gagg-jmmfafir 

A-22 
A- 7 
A-9 
A- 7 
A- 7 
A-9 
A-7 
A-1 6 
A-1 6 
A-1 7 
A-1 4 
A-1 4 
A-1 4 
A-1 4 
A-27 
A-1 6 
A-1 1 
A-1 1 
A-1 1 
A-24 
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def_detail_part 

A-8 

definition 

A-8 

def_name_part 

A-8 

def_spec_part 

A-8 

equivalencejist 

A-1 2 

ida 

A-21 

idajmppart 

A-21 

ida_name_part 

A-21 

ida_spec_part 

A-21 

lib_int_name_part 

A-25 

lib_int_spec_part 

A-25 

library 

A-26 

library_imp_part 

A-26 

library  interface 

A-25 

libraryname^part 

A-26 

library_spec 

A-27 

library  _spec_part 

A-26 

network_imp_part 

A-1 0 

port_port_connect 

A-1 2 

port_spec 

A-9 

port__window_connect 

A12 

root 

A-1 8 

root_name  _part 

A-1  8 

root_spec_part 

A-1 8 

server 

A-23 

server_imp_part 

A-23 
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server_name_part 

A-23 

simple_acc_int_spec_part 

A-7 

si  m  ple_act_i  m  p_part 

A-1 5 

simple_ida__imp_part 

A-22 

simple_server_imp_part 

A-23 

simple_subroot_imp_part 

A-20 

sub-eiement_link 

A-1  7 

subjnt_name_part 

A-1 8 

subroot 

A-1 9 

subroot_imp_part 

A-1 9 

subrootjnterface 

A-1 8 

subroot_name_part 

A-1 9 

subroot_spec_part 

A-1 9 

subsys_name_part 

A-1 0 

subsys_spec_part 

A-1  0 

subsystem 

A-1 0 

system 

A-1  3 

system_imp_part 

A-1  3 

system_name_part 

A-1  3 

system_spec_part 

A-1  3 

temp_const_ident 

A-24 

temp_const_spec 

A-24 

window_spec 

A-9 

with_section 

A-8 
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p 


A-  6 
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acc  int  array  d 


ARRAY 


l 


< 
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Neither  a  composite  IDA  nor  a  composite  server  may  refer  to  a  composite 
access  interface  in  its  USES  list. 
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i8 


simple  act  imp  part 


A 


A 
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A  composite  subroot  may  not  contain  a  component  derived  from  a  root  template 
but  must  contain  a  root  component  derived  from  a  subroot  template.  This  latter 
component  gives  the  interface  to  the  composite  template. 
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ida 


ida_name_part 


!®D 


L-J 

ida_spec_part 

] 

J 

r 

L  ^ 

\da  imn  nnrt 

^  w 

ida  name  part 


ida_spec  pan 


A24 


ida  imp. .pan 


A22 


< 


simple_idajmp_part 


A10 


network_imp_part 


A  composite  IDA  may  contain  only  IDA,  channel,  pool  and  library  components. 
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simple_server_imp_part 


A10 


J  network_imp_part  L 


A  composite  server  must  contain  at  least  one  server  component  and  may  also 

contain  IDA,  channel,  pool  and  library  components. 
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const  identifier 
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in 


library 


lib  mt  name  part 


c 


LIBRARY  INTERFACE 


X 


identifier 


lib  mt  spec  part 


A8 
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[  LIBRARY  >-[ 


identifier 


* 


5rary  spec  pal 

A24 


C'-W  imp  p.Tt 


AS 


Variables  may  not  be  declared  in  a  library  implementation  part. 


Appendix  A  Syntax 


A  -  26 


Mascot  Version  3.1 


library  spec 


comp  acc  int  spec  part 


I 
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BACHUS  .  NAUR  FORM  OF  SYNTAX 


The  form  of  Bachus  Naur  syntax  used  is  as  follows  - 

a)  Normal  font  lower  case  words,  some  containing  embedded  underlines,  are  used  to 
denote  syntactic  categories. 

b)  Bold  font  words  and  symbols  are  used  to  denote  Mascot  reserved  words  and  symbols, 

c)  Underlined  words  are  used  to  reference  Pascal  constructs  For  further  expansion  of 
these  constructs  refer  to  a  Pascal  syntax  definition 

d)  Italicised  prefix  words  are  used  to  convey  semantic  qualification  of  the  following 
non-italic  root  For  example,  if  an  identifier  is  required  which  must  be  the  name  ol  a 
template,  the  following  compound  name  is  used 

template  identifier 

ei  Square  brackets  enclose  optional  items  (NB  Bold  square  brackets  occur  in  the  syntax 
definition  These  refer  to  symbols  in  the  Mascot  design  language  ) 

'  Braces  enclose  a  repeated  item  The  item  may  appear  zero  or  more  times 

g  A  vertical  bar  separates  alternatives  Ihov  are  always  used  to  separate  alternative:' 

for  the  construct  being  defined  never  as  alternatives  for  part  of  a  construct 


access  interface  -  access  interface  name  pari  ; 
access  interface  specification  pari  end  . 

access  interface  name  pari  =  access  Interface  identifier 

simple  access  interface  specification  part 

[with  section)  access  interlace  detail  part 
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with_section  ::= 

with  definition  identitier  {,  definition  identifier!  ; 
procedures  functio sheading  ::=  procedure  heading  |  function  heading 

definitionunit  ::= 

definition  _name_part  ;  definition_specification_part  end  . 

definition  .name,  part  ::=  definition  identifier 

definition  specificationjaart  ::= 

[with  section]  definition_detail _part 

definition  detaii  part  ::= 

constant  definition  Dart 
|  fconstant  definition  part]  type  definition  part 

port  specification  ::=  requires  access  jnterface_declaration 
{access  interface,  declaration) 

access  interface  .declaration  :  = 

identifier  list  :  access  jnterface.definition  ; 

window_.specification  ::=  provides  access Jnterface_declaration 
{access.  interface_declaration) 

Partially  in  Section  2.3.  fully  in  Section  2.13 


access  interface  definition  ::=  access  intedace  identifier 
|  access  interface. array,  description 

Partially  in  Section  2.3,  fully  in  Section  2.14 

accessjnterface.  specifications^  ::= 

simple_access_interface_specificafion_part 
|  composite,  access  jnterfacespecification_par| 
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Partially  in  Section  2.3.  fully  in  Section  2.15 


accessjnterface_detail_part  ::= 

[read_only_constant_specifications] 

|  [read_only_constant_specifications]  variable_specifications 
|  [read_only_constant_specifications]  [variable_specifications] 
procedure_or_function_heading  {procedure_or_function_heading} 

Section  2.4 

subsystem  ::=  subsystem_name_part  ;  subsystem_specification_part 
networkJmplementation_part  end  . 

subsystem  name_part  ::=  subsystem  identifier 

network  implementation^part  ::= 

uses  template_defmition  {,  template_definition}  ; 
component  {component}  [equivalence  {;  equivalence}] 

component  ::=  component_class  identifier  :  template  identifier 
[connection  specification]  ; 

component  class  :=  activity  |  subsystem  [  server  | 

|  ida  |  channel  |  pool  |  library 

connection  specification  .:=  (  connection  (,  connection}  ) 

port  window  connect  ::=  port  identifier  -  component  identifier 
.  window  identifier 

system  ::=  system_name_part  ;  system  specification  part 
system  implementation  part  end  . 

system  jname _part  ::=  system  identifier 

system  implementation  part  ::=  uses  template  identifier 
{,  template  identifier!  ;  component  {component} 
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Partially  in  Section  2.4,  fully  in  Section  2.8 


subsystem  specification, part  ::=  [template_constant_definition] 

[window  _specification]  [port_specification] 

connection  template  constant  ^identity 

[  port  window  connect  |  port_port_connect 

Partially  in  Section  2.4.  fully  in  Section  2.14 

template_detimtion  ::=  composite  access  interface  identifier 
j  template  identifier 

port_port  connect  =  port  identifier  =  port  definition 

port_definition  ::=  boundary  port  identifier 

|  composite  port  identifier .  comprises  identifier 

equivalence  ::=  window  window  equivalence  |  window_port_equivalence 

window  window  equivalence  ::=  window  declaration  =  component  identitier 
.  window  identifier 

window  port  equivalence  =  window  declaration  =  port_definition 

window  declaration  =  boundary  window  identifier 

i  composite  window  identifier .  comprises  identitier 

Section  2.5 

activity  ::=  activity  name  part  ;  activity  specif ication_part 
activity  implementation  part  end  . 

activity,  name  part  -  activity  identifier 

Partially  in  Section  2.5.  fully  in  Section  2.8 

activity  specification  part  -  [template__constant_specificationj 
[port  specification] 
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Partially  in  Section  2.5.  fully  in  Section  2.9 


simple_activityjmplementation  jjart  ::=  [withsection] 
[library_specification]  (declaration  pari] 
compound  statement 

Partially  in  Section  2.5.  fully  in  Section  2.12 

activity  implementation  part  ::=  simple  activity  implementation  part 
|  composite  activity  implementation  part 

Section  2.6 

idaname  part  -  ida  class  identifier 

ida  class  :  =  channel  |  Ida  l  pool 

access  equivalence  .:=  renaming  equivalence  i  simple_equivalence 

renaming  equivalence  - 

window  identitier .  access  interface  declaration  identifier 
=  renamed  declaration 

renamed  declaration  = 

internal  declaration  identifier 
j  pod  identifier  pod  declaration  identifier 

simple  equivalence  window  identPor  =  pod  identitier 

Partially  in  Section  2.6.  fully  in  Section  2.8 

ida  specification  part  =  [template  constant  specification] 
window  specification  [port  specification] 

Partially  in  Section  2.6.  fujiy  m  Section  2.9 

ida  =  ida  name  part  ;  ida  specification  part 
ida  implementation  part  end  . 
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simple  jda  implementation  jaart  ::=  [withsection] 
[library  specification]  declaration  part 
[access^equivalence  {;  access_equivalence}] 


Partially  in  Section  2.6.  fully  in  Section  2.10 

idaJmplementation_part  ::=  simple  Jda  Jmplementation_part 
|  network  implementation  jsart 

Section  2.7 

server  name  part  ::=  server  identitier 

Partially  in  Section  2.7,  fully  in  Section  2.9 

server  ::=  server  name  part  ;  ida„specification  part 
server  implementation  part  end  . 

simple,  server  implementation  part  ::=  [with_section] 

[library  specification]  declaration  part 
[access  equivalence  {.  access,  equivalence]] 

server  implementation  part  =  simple,  server Jmplementationpart 
|  network  implementation  part 

Section  2.8 

system  specification  part  =  [template, constant^specification] 

template  constant  specification  = 

constant  template  constant  group  {template_constant_group} 

template  constant  group  :=  identifier  list  : 

(  array  [  Integer  {,  Integer }  ]  of  ]  standard  scalar  type 

template^constant  identity  ::= 

template  constant  identifier  =  template  constant  definition 
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template_constant_definition  :  = 
( constant  {,  constant} ) 

|  constant 

|  constant  identifier 

Section  2.9 


libraryjnterface  ::=  library Jnterface_name_part ; 
library  _interface_specificationj>art  end  . 

library Jnterface_name_part  ::=  library  Interface  identifier 

library  interface^specification  part  ::=  [withsection] 

procedure_orJunction_heading  (procedure_or_function_heading) 


library  ::=  library  name-part  ;  library_specification_part 
library  implementation  part  end  . 

library  name  part  ::=  library  identifier 


library  specification  part  ::=  [template  .constant  specification) 
gives  library  Jr, 

{,  library  i, 


library  implementation  jjart  ::=  [with  section]  [library  specification) 
library  declarative j>art 


library  declarative,  part  ::=  [constant  definition  part] 

[type  definition  parti  procedure  and  function  declaration  part 


library  specification  :=  library  library  Interface  identifier 
{,  library  interlace _ 


Section  2.12 


composite_activity  implemention  part  ::= 

uses  template,  definition  {,  template  identifier!  ; 
activity  component  part  (activity  component,  part) 
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activity_component_parl  ::=  activity  component  class  identifier 
:  template  identifier  [activity  connection  specification]  ; 

activity_component_class  ::=  root  |  subroot  |  library 

activity_connection_  specification  ::=  (  activity_connection 
{,  activity_connection)  ) 

activity  connection  ::=  template  ^constant  identity 
|  sub_element_link  |  port  jiorj  connect 

sub^element  Jink  ::=  out  link  identifier  =  subroot  identifier 

root  ::=  root  name  part  ;  root  specification  part 

simple  activity  implementation  part  end  . 

root_name  _part  =  root  identifier 

root  specification  _part  ::=  [activity  _  specification  jDart] 

[needs  Jist] 

needs_list  ::=  needs  needed^  interlace  {needed  Jnterface) 

neededjnterface  = 

identifier  list  :  subroot  interface  identifier ; 

subroot  Jnterface  ::=  subroot_interface_name_part  ; 

simple_accessJnterface_specification_part  end  . 

subrootjnterface^namejoart  ::=  subroot  interface  identifier 

subroot  ::=  subroot_name_part  ;  subroot  _specification_part 
subrootJmplementation_part  end  . 

subroot_name_part  ::=  subroot  identifier 

subroot_specification_part  ::=  activity  specification  _part 
gives  subroot  interlace  identifier  ;  [needsjist] 


subroot  implementation_part  ::=  simp!e_subroot  implementation  _part 
|  composite_activityJmplementation_part 
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simple  subroot  implementation_part  ::=  [with_section] 
[library  specification]  declaration  part 


Section  2.13 


access_  interface^array^description  ::= 

array  [  simple  type  {,  simple  type)  ]  of 


access 


Section  2.14 


composite  access  interface.  specification_part  ::= 

comprises  comprise  declaration  {comprise_declaration} 

comprise  declaration  ::= 

identifier  list  :  access  interlace  identifier  ; 

SssliflUiLlS 


read  only  constant  specifications  ::= 

pa-ameter  pmup  {parameter  group) 

-arable  st  ecifications  := 

var  parameter  group  (parameter  group) 


Append'x  B 


mascot  3  unit  definition  unit  |  interface  unit  |  template.unit 

interface  unit  =  access  interface  |  subroot  .interface 
I  library  interface 

template  unit  =  system  |  subsystem  |  activity  |  server  |  ida  |  root 
|  subroot !  library 
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SYNTAX  INDEX 


In  the  list  given  below,  each  syntactic  category  is  followed  by  the  section  where  it  is  defined  In  addition, 
each  syntactic  category  is  followed  by  the  names  of  other  categories  in  whose  definition  it  appears.  An 
ellipsis  (...)  is  used  when  the  syntactic  category  is  or  can  be  a  reserved  word  or  symbol  All  uses  of 
parentheses  are  combined  in  the  form "()".  The  italicised  prefixes  used  with  some  terms  are  deleted  here 


access 

access_intertace_name_part  2.3 

access_equivalence  2.6 

simplejdajmplementation _part  2.6,  2.9 

simple_server_implementation _part  2.7,  2.9 

aocessjnterface  2.3 

interface_unit  Appendix  B 

access_interface_array_description  2.13 

accessjnterface  definition  2.3,  2.13 

accessjnterface  declaration  2.3 

port  specification  2 . 3 

window  specification  2.3 

access  Jnterface_  definition  2.3,  2.13 

access__irrterface_declaration  2.3 

access  interface  detail  part  2  3,  2.15 

simple_accessJnterface_specification  _part  2  3 

access_interface_name  _part  2  3 

accessjnterface  .  2.3 

access_interface_specificationjDart  2  3,  2.14 

acoessjnterface  2  3 
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activity 


2  5, 

activity  name  part  2.5 

component  class  2  4 

template  unit  Appendix  B 

activity  component  _class  2.12 

activity  component _part  2.12 

activity  component  part  2.12 

composite  activity  implementation jaart  2  12 

activity  connection  2.12 

activity  connection  specification  2.12 

activity  connection  specification  2.12 

activity  component  part  2.12 

activity  implementation  part  2  5,  2.12 

activity  2  5 

activity  name  part  2.5 

activity  2.5 

activity  specification  part  2  5,28 

activity  2  5 

root  specification  _part  2.12 

subroot  specification  part  2  12 

array 

access  interface  arrayjjescription  2.13 

template  constant  group  2  8 

channel 

ida  class  2  6 

component  class  2  4 

component  2.4 

network  implementation_part  2.4 

system  implementation  joart  2  4 
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component_class  24 

component  24 

composite_access_interface_speci<ication  _part  2.14 

access_inter1ace_specification_part  2.3,  2.14 

composite_activity_implementation_part  2.12 

activity  Jmplementation_part  2.5,  2.12 

subroot  Jmplementation_part  2.12 

compound_statement  Pascal 

simple  activityJmplementation_part  2.5,  2.9 

comprises 

composite,  access Jnterface_specification_part  2.14 

comprisejjeclaration  2.14 

composite  access.  interface_specification_part  2.14 

connection  2.4,  2.8, 

connection  specification  2.4 

connection  specification  2.4 

component  2.4 

constant  Pascal,  ... 

template  constant_definition  2  8 

template  constant_specification  2.8 

constant  definition  part  Pascal 

definition  detail _part  2.3 

library  declarative jpart  2.9 
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declaration  part  Pascal 

simple^activityjmplementationjaart  2.5,  2.9 

simple_ida_implementation_part  2  6,  2  9 

simple_server_implementation_part  2.7,  2.9 

simpie_subrootJmplementation_part  2.12 


definition 

definrtion  name __part  2.3 

definition  detaiLpart  2.3 

defmition_specification_part  2.3 

definition  umt  2.3 

mascot  3_unit  Appendix  B 

defimtio '  name__part  2  .3 

defmition_unit  2.3 

definition  specification  part  2.3 

definition  unit  2.3 

end 

access,  interface  2  3 

activity  2.5 

definition  unit  2.3 

ida  2  6,  2  9 

library  2  9 

library  interface  2.9 

root  2  12 

server  2.7,  2  9 

subroot  2.12 

subroot  interface  2.12 

subsystem  2.4 

system  2  4 

equivalence  2  4,  2.14 

network  implementation joart  2.4 

function  heading  Pascal 

procedure  or  function  heading  2  3 
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gives 


library  specif ication_part 

2.9 

subroot_specification  _part 

2.12 

ida 

2.6,  2  9,  ... 

component_class 

2.4 

ida_class 

2.6 

template_unit 

Appendix  B 

ida_class 

2.6 

ida_nartiej3ari 

2.6 

idaJmplementation_part 

2  6,  2  10 

ida 

2.6,  2.9 

ida_name_part 

2.6 

ida 

2  6,  2  9 

ida  ^specification  j>an 

2.6,  2.8 

ida 

2.6,  2  9 

server 

2.7,  2.9 

identifier  Pascal 

access  jnterface_arrayjjescription  2.13 

access  _interface__definition  2.3,  2.13 

access  jntertacejiame  _part  2.3 

activity  component_part  2.12 

activity  namejaarl  2.5 

component  2  4 

composrte_activity  implementation  _part  2.1  12 

comprise  declaration  2  14 

definition  name _par1  2.3 

ida_name  _part  2  6 

library_interface_name_part  2  9 

libraryname  _part  2  9 

library  specification  2  9 

library  specif icationjaart  2  9 

needed  Jnterf  ace  2  12 

portdefinition  2  4.2  14 

port _port_connect  2  4.  2  14 

porlwindow  connect  2  4 
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'cn.imed  declaration 

2.6 

renaming  equivalence 

2  6 

root  name  pari 

2.12 

server  name_par1 

2.7 

simple  equivalence 

2.6 

sub  element  link 

2.12 

subroot  interlacepamejoart 

2.12 

subroot  name  part 

2.12 

subioot  specification_part 

2.12 

subsystem  name,  part 

2.4 

system  implementation  part 

2.4 

system  name  part 

2.4 

vmpiate  constant  definition 

2  8 

•(.-•••p'ate  constant  identity 

2.8 

ten  >  i.tte  definition 

2.4,  2.14 

widow  declaration 

2.4,  2.14 

window  window  equivalence 

2.4,  2  14 

with  section 

2.3 

Pascal 

interface  declaration 

2  3 

■'  (  declaration 

2.14 

"  .•■  .fed  interface 

2.12 

■  -  :  ate  constant  group 

2.8 

•empiate  constant  group 

2.8 

a;. cess  interlace _  name _part 

2.3 

Prary  interface  name-part 

2.9 

subroot  interface  namejaart 

2.12 

e  urnt 
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■  w  ■■■■  . . —  » 

library  2  9,  ... 

acti  vity_component_class  2.12 

component_class  2.4 

library  Jnterface_name_part  2.9 

library  _name_part  2.9 

library  specification  2.9 

template_unit  Appendix  B 

library  _declarative_part  2.9 

library  _implementation_part  2.9 

libraryJmplementation_part  2.9 

library  2.9 

libraryinterface  2.9 

interface_unit  Appendix  B 

library  Jnterface_namejDart  2  9 

library  interface  2.9 

library  _interface_specification_part  2.9 

library  interface  2.9 

library  name j>art  2.9 

library  2.9 

library  specification  2.9 

library  implementation _part  2.9 

simple_activityJmplementation_part  2.5,  2.9 

simpleJda_implementation_part  2  6,  2  9 

simple_server_implementation_part  2.7,  2.9 

simple_subrootJmplementation_part  2.12 

library  specif ication  part  2.9 

library  2  9 

mascot_3_unit  Appendix  B 

needs 

needsjist  2  12 
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needsjist  2.12 

root_specification_part  2.12 

subroot_specification_part  2.12 

neededjnterface  2.12 

needs_list  2.12 

networkjmplementation  _part  2.4 

idaJmplementation_part  2.6,  2.10 

serverJmplementation_part  2.11 

subsystem  2.4 


of 


access  jntertace_array_description  2.13 

template_constant_group  2.8 

parameter  _group  Pascal 

read_only_constant_specification  2.15 

variable_specifications  2.15 


pool 

componentclass  2.4 

Ida  class  2  6 

port  definition  2.4,  2.14 

port  port  connect  2.4,  2.14 

window  port  equivalence  2.4,  2.14 

port^ port  connect  2.4,  2.14 

activity  ^connection  2.12 

connection  2.4,  2.8 

port  specification  2.3 

activity„specification_parl  2.5,  2.8 

ida  specificationjDart  2.6,  2  8 

subsystem_specification_part  2.4,  2.8 

port_window_connect  2.4 

connection  2.4,  2.8 
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procedure_and_function_declaration_part  Pascal 

library_declarative  _part  2.9 

procedure_or_function_heading  2.3 

access_interface_detail _part  2.3,  2.15 

library  _intertace_specification_part  2 .9 

procedure_heading  Pascal 

procedure_or_function_heading  2.3 

provides 

window_spedfication  2.3 

read_only_conslant_specifications  2.15 

access_interface_detail_part  2.3,  2.15 

renamed_declaration  2.6 

renaming^equivalence  2.6 

renaming_equivalence  2.6 

access^equivalence  2.6 

requires 

port  specification  2 . 3 

root  2.12,  ... 

activitycomponentclass  2  12 

root_namejoart  2  12 

template^unit  Appendix  B 

root_name__part  2  12 

root  2.12 

root_specification_part  2.12 

root  2,12 

server  2.7,  2  9. 

component_class  2.4 

server_name  _part  2.7 

template_unit  Appendix  B 
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server  Implementation _part 

2.7,  2.9 

server 

2.7,  2.9 

server_name_part 

2.7 

server 

2.7,  2.9 

simple_access_interface_specification_part 

2.3 

acce  ss  _i  nte  rf  ace_specitication_part 

2.3,  2.14 

subrootjntertace 

2.12 

simple_activity_implementation  _part 

2.5,  2.9 

activity  Jmplementation_part 

2.5,  2.12 

root 

2.12 

simple  equivalence 

2.6 

access_equivalence 

2.6 

simple  ida  implementation  part 

2.6,  2.9 

idajmplementation  _part 

2.6,  2.10 

simple  server  implementation jaart 

2.7,  2.9 

server  jmplementationjDart 

2.7,  2.9 

simple  subroot jmplementation_part 

2.12 

subroot  Jmplementation_part 

2.12 

simple  Jype 

Pascal 

access  jntertace_array_description 

2.13 

standard  scalar  type 

Pascal 

template_constant_group 

2.8 

sub  elementjink 

2.12 

activity^connection 

2.12 

subroot 

2  12,  ... 

activity_component_class 

2.12 

subroot_inter1ace_name_part 

2  12 

subroot_name_part 

2  12 

template_umt 
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subroot  Jmplementation_part 

2  12 

subroot 

2.12 

subrootjnterface 

2.12 

interface_unit 

Appendix  B 

subroot  Jnterface_name_part 

2.12 

subrootjnterface 

2.12 

subroot_name_part 

2.12 

subroot 

2.12 

subroot_specification_part 

2  12 

subroot 

2.12 

subsystem 

2.4,  ... 

component_class 

2.4 

subsystem_name  j>art 

2.4 

templateunit 

Appendix  B 

subsystem  name  part 

2.4 

subsystem 

2.4 

subsystem  specification  part 

2.4,  2.8 

subsystem 

2  4 

system 

2.4,  ... 

system  name  _part 

2.4 

template_unit 

Appendix  B 

system  implementation._part 

2.4 

system 

2.4 

system_namej3art 

2.4 

system 

2.4 

system_specification_part 

2.8 

system 

2.4 
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template,  constant_def  inition  2 . 8 

subsystemspecificationjaart  2.4,  2.8 

template_constantJdentity  2.8 

temp!ate_constantJdentity  2.8 

activity_connection  2.12 

connection  2.4,  2.8 

template,  constantgroup  2.8 

template  „constant_specification  2.8 

template_j;onstant_specif  ication  2 .8 

activity_specification_part  2.5,  2.8 

ida .specification jaart  2.6,  2  8 

library  specif ication_part  2.9 

system  specification  jaart  2.8 

template  definition  2  4,  2  14 

composite_activity  implementation  jaart  2.12 

network  implementation  jaart  2.4 

template.unit  Appendix  B 

mascot_3_unrt  Appendix  B 

typedefimtion  jaart  Pascal 

definition  detail  jaart  2  3 

library  declarative  jaart  2.9 

uses 

composite,  activity  implementation  _par!  2  12 

network  implementation jaart  2  4 

system  implementation  jaart  2  4 

var 

variable.specificatkans  2.15 

va  riable  .specif  ications  2.15 

access  jnterface_detailjaart  2.3,  2.15 
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window_declaration 

2.4,  2.14 

window_window_equivalence 

2.4,  2  14 

window_port_equivalence 

2.4,  2.14 

window_window_equivalence 

2.4,  2  14 

equivalence 

2.4,  2.14 

window  j3ort_equivalence 

2.4,  2.14 

equivalence 

2.4,  2.14 

window__spedfication 

2.3 

ida_specification_part 

2.6,  2  8 

subsystem_specification_part 

2.4,  2  8 

with 

withsection 

2.3 

with_section 

2.3 

definitionspecificationjaart 

2.3 

library  implementation  jDart 

2.9 

library  interlace. specification  _part 

2.9 

simple_accessJnterface_specification_part 

2.3 

simple_activityjmplementation_part 

2.5,  2  9 

simple  Jda_implementation_part 

2.6,  2.9 

simple_server_implementation_part 

2.7,  2  9 

simple_subrootjmplementation_part 

2.12 

0 

activity  connection  specification 

2.12 

connectionspecitication 

2.4 

template_constant_definition 

2.8 

access_inter1ace_array_description 

2.13 

activity_connection_specification 

2.12 

composite_activityJmplementation_part 

2.12 

connect  ionspecification 

2.4 

libraryspecitication 

2  9 

libraryspecification  _part 

2  9 

network  Jmplementation_part 

2  4 

system  Jmplementation_part 

2.4 
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template_constant_definition  2.8 

template_constant_group  2.8 

with_sectbn  2.3 

access Jntertace  2 . 3 

activity  2.5 

definitbnunit  2.3 

ida  2.6,  2  9 

library  2  9 

libraryjnterface  2  9 

port_definition  2  4,  2.14 

port  windowoonnect  2.4 

renamed  jleclaration  2  6 

renamingequivalence  2.6 

root  2.12 

server  2  7,  2.9 

subroot  2.12 

subroot  Jntertace  2.12 

subsystem  2.4 

system  2.4 

window_dec1aration  2  4,  2.14 

window_window_equivalence  2  4,  2  14 

activity_component_part  2.12 

access  Jrrtertace_declaration  2.3 

component  2.4 

comprise_declaration  2  14 

needed  Jntertace  2.12 

template  j:onstant_group  2.8 

access  Jntertace  2.3 

access  Jnter1ace_declaration  2.3 

activity  2.5 

activity  _componentj>art  2.12 

component  2.4 

composite_activrty_implementation  jDart  2.12 

comprise  jteclaration  2.14 

detinitbn_unit  2.3 
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ida  2  6,  2.9 

library  2.9 

library  ^interface  2.9 

library  ^specification  2  9 

library  _specification  _part  2.9 

needed  ^interface  2.12 

network  JmplementationjDart  2.4 

root  2.12 

server  2.6,  2.9 

simpleJdajmplementation_part  2.6,  2.9 

simple_serverJmplementation_part  2.7,  2.9 

subroot  2.12 

subroot  Jnterface  2.12 

subroot_specification_part  2.12 

subsystem  2  4 

system  2.4 

system  implementation  part  2.4 

with_section  2  3 

port  j)ort_connect  2  4,  2.14 

port  window  connect  2  4 

renaming  equivalence  2  6 

simple_equivalence  2.6 

sub  element  Jink  2.12 

template  constant  identity  2  8 

window  port  equivalence  2.4,  2.14 

window_window_equivalence  2  4,  2.14 

[) 

access  Jnterface^array_description  2.13 

template^constantgroup  2.8 
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Mascot  Software 


.1  E 
c n  o 


B  a, 

I  • 

q.  a. 
E  E 

O 

O  *“ 


0) 

CL 


E 


co 


0) 

i/5 

o 

a 

E 

o 

O 


c 

o 

ra 

o 

»*• 

o 

fl> 

a. 

t/) 


c 

o 

ra 

o 

o 

c> 

CL 

</) 
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'J/jadc/w^d  roni  indicates  Mandatory  Module  Types 


Template  Modules  I  Specification  Modules 


USE 

OF  KEYWORDS 

CONSTANT 

PROVIDES 

REQUIRES 

GIVES 

NEEDS 

COMPRISES 

WITH 

USES 

LIBRARY 

</> 

O) 

D 

Definition 

0+  - 

O 

2 

Simple  Access  Intedace 

- 

- 

- 

- 

- 

- 

0+  - 

c 

o 

Subroot  Interface 

- 

- 

- 

- 

- 

- 

0+  -  - 

CO 

o 

Library  Interface 

- 

- 

- 

- 

- 

- 

0+  - 

o 

d» 

CL 

c r> 

Composite  Access  Inteface 

1  + 

a 

Specification 

Implementation 

■ 

Dependencies 

Dependencies 

Simple  IDA  ' 

0+ 

1  + 

0+ 

- 

- 

■ 

0+  -  0+ 

CO 

<D 

Simp.e  Activity 

0+ 

- 

0+ 

* 

- 

- 

0+  -  0+ 

"5 

■o 

Smrj’e  Root 

0+ 

- 

0+ 

- 

0+ 

- 

0+  -  0+ 

o 

2 

Simp  e  S.ibroot 

0+ 

- 

0+ 

1 

0  + 

- 

0+  -  0+ 

0) 

CO 

L  b  ra  ry 

0+ 

- 

- 

1  + 

- 

- 

0+  -  0+ 

Q. 

E 

<u 

Composite  IDA 

0+ 

1  + 

0+ 

- 

- 

- 

-  1+  0+ 

Composite  Activity 

0+ 

- 

0+ 

- 

- 

- 

-  1+  0+ 

Composite  Subroot 

0+ 

- 

0+ 

1 

0+ 

- 

-  1+  0+ 

Subsystem 

0+ 

0+ 

0+ 

- 

- 

- 

-  1+  0+ 

System 

0+ 

- 

- 

- 

- 

- 

•  1+  0+ 

-  =  Prohibited  1  =  One  and  only  one 

1+  =  One  or  More  0+  =  Zero  or  more 


Channel.  Pool  and  Server  have  identical  characteristics 
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DEFINITION  OF  GRAPHICAL  CONVENTIONS 


The  purpose  of  documentation  is  to  convey  information  to  the  reader.  One  technique  for  achieving  this  is 
the  use  of  diagrams.  The  Mascot  definition  contains  equivalent  graphical  and  textual  design 
representations.  Conventions  are  defined  for  annotating  the  diagrams  in  the  graphical  representation  so 
that  they  reflect  all  but  the  program  code  of  the  corresponding  modules  However,  a  diagram  containing 
too  much  detail  can  actually  convey  less  information  than  a  less  detailed  diagram  The  optimum  level  of 
detail  could  well  depend  on  the  purpose  for  which  the  diagram  is  intended.  Design  and  implementation 
documents,  for  example,  form  two  relatively  independent  sets.  Documents  may  be  explanatory  or 
definitive  in  purpose  In  the  course  of  design,  omission  of  detail  may  reflect  the  postponment  of 
decisions. 

The  definition  recognises  sufficient  variability  in  the  use  of  the  standard  graphic  conventions  to  allow  for 
local  variance  and  for  the  desirability  of  employing  different  levels  of  detail  for  different  purposes  provided 
that  consistency  is  maintained  within  sets  of  related  documents 


Svmboloav 


Symbols  are  introduced,  in  the  appropriate  sections  of  the  Handbook,  for  the  various  entities  employed 
in  Mascot  designs  This  appendix  presents  the  complete  set  of  symbols  and  is  to  be  regarded  as  the 
definitive  document  for  this  purpose. 


Simple  Forms 

The  simple  forms  of  activities,  channels,  pools,  generalised  IDAs,  servers  and  subroots, 
together  with  roots,  constitute  the  elements  and  subelements  of  a  Mascot  design  (see 
Appendix  B)  They  are  symbolised  as  follows. 


Simple  Activity 
Root 

Simple  Subroot 


In  accordance  with  long  established  Mascot  practice,  the  circular  form  should  normally  be  used.  The 
rounded  rectangular  form  is  appropriate  where  it  is  desirable  to  provide  additional  space  for  the 
presentation  of  information  within  the  boundary  of  the  symbol.  This  might  be  the  case,  for  example,  with 
an  activity,  root  or  subroot  which  possesses  an  unusually  large  number  of  network  and'or 
subelement  connections 
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Simple  IDA 


Pool 


Channel 

The  channel  and  pooi  symDois  are  cased  on  those  used  in  earlier  versions  of  Mascot.  These  have 
been  modified  so  that,  like  the  activity  symbols,  they  allow  information  to  be  presented  within  the 
boundary  of  the  symbol.  They  may  be  used  where  an  IDA  conforms  to  the  accepted  definition  (see 
Section  2.6)  of  one  of  these  special  forms.  The  rectangular  symbol  is  a  generalised  form  of  IDA.  it  may  be 
used  to  represent  any  IDA  but  must  be  employed  where  the  IDA  in  question  is  not  strictly  a  channel  or 
a  pool 


Simple  Server 


The  symbol  which  represents  a  server  is  a  combination  of  those  representing  activities  and  IDAs.  It 
thus  emphasises  the  hybrid  nature  of  the  server  which  behaves  in  the  passive  manner  of  an  IDA  as  far 
as  network  interactions  are  concerned  but,  by  virtue  of  being  permitted  to  contain  interrupt  handlers, 
also  possesses  an  active  aspect.  If  the  device  to  which  the  server  is  connected  is  also  to  be  depicted  on 
the  diagram,  it  should  be  in  the  form  shown  below: 


Device 

(with  connection 
to  server) 


The  hatched  rectangle  may,  however,  may  be  replaced  by  a  schematic  drawing  of  the  device. 


Composite  Forms 

The  same  symbol  is  used  to  represent  a  template  and  a  component.  By  definition,  a  component 
must  be  part  of  a  composite  template.  This  may  be  a  system  or  a  subsystem: 
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which  is  symbolised  by  any  smooth  closed  curve,  drawn  with  a  thicker  line  than  that  used  for  the  simple 
entities,  but  should  normally  take  the  form  of  a  rounded  rectangle. 


For  the  composite  forms  of  activity,  IDA,  server  or  subroot,  the  symbols  used  are  the  same  as  for 
the  simple  forms  but  normally  drawn  with  thicker  lines  as  they  are  throughout  the  Handbook. 


Composite  Activity 
Composite  Subroot 


Composite  Server 


Alternatively,  for  all  the  composite  forms,  double  lines,  or  some  other  convenient  locally  defined  means 
of  making  the  distinction,  may  be  used  The  same  convention  should  be  employed  to  denote 
composite  components  where  the  information  is  known  and  is  considered  relevant. 

Paths,  Ports  and  Windows 

Symbols,  illustrated  below,  are  defined  for  simple  ports  and  windows  and  the  path  which  joins  them. 
The  lines  which  denote  data  paths  may,  if  desired,  be  drawn  as  curves.  Arrowheads  are  used  to  denote 
the  direction  of  data  flow  and  should  normally  be  shown. 
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Path 


Window 


There  are  special  rules  governing  the  placement  of  ports  and  windows  in  servers: 


The  windows  should  appear  on  the  straight  edge  opposite  to  the  semi-circular  end  of  the  symbol  and 
the  ports  on  either  of  the  two  adjacent  sides. 

Where  paths  pass  through  the  boundaries  of  enclosing  composite  design  entities,  port  or  window 
symbols  and  data  flow  arrowheads  are  repeated  at  each  boundary: 

Path  through 
Constructional 
Boundaries 


Since  any  number  of  ports,  of  the  appropriate  type,  may  be  connected  to  a  single  window,  diagrams 
frequently  depict  paths  which  merge.  Normally,  these  lines  are  joined  at  a  window.  However,  where  it  is 
more  convenient,  they  may  be  merged  at  an  intermediate  point  provided  that  merging  is  in  the  direction 
from  port  to  window  This  is  illustrated  in  the  diagram  below  in  which  the  direction  of  data  flow  has 
deliberately  been  omitted  as  irrelevant  to  the  point  at  issue. 

Merging 
Paths 

Subelements  and  Subelement  Links 

The  subelement  links,  between  the  components  of  a  composite  activity,  are  represented 
graphically  as  follows 
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where  the  hollow  arrowheads  indicate  the  direction  of  procedure  invocation  and  may  be  repeated  where 
the  link  crosses  enclosing  boundaries: 


Subroot  Link 
through 

Constructional 

Boundaries 


Links  may  be  merged,  in  a  manner  similar  to  that  employed  for  paths,  in  the  direction  of  procedure 
application: 


V  Merging 

Subelement  Links 

Composlt  Paths,  Ports  and  Windows 

For  the  template  in  which  a  composite  access  Interface  is  decomposed  into  its  constituent 
Interfaces,  special  symbols  are  defined  to  denote  the  composite  ports  and  windows  At  this  level 
of  decomposition,  the  composite  path  should  be  denoted  by  a  thick  (or  double)  line,  where  this  is 
considered  relevant: 
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composite 

port 


composite  path 


composite 

window 


The  port  and  window  at  each  end  of  a  composite  path  may  be  represented  by  a  proportionately 
larger  than  normal  port  or  window  symbol  if  so  desired. 


Composite  Port 


The  internal  structure  of  a  composite  port  is  represented  by  a  semi-circle,  drawn  with  a  thick  line,  and 
with  its  component  ports  illustrated  inside  the  boundary 


Composite  Window 


The  internal  structure  of  a  composite  window  is  represented  by  a  rectangle,  drawn  with  a  thick  line, 
and  with  its  component  windows  illustrated  inside  the  boundary 
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Annotation 

A  template  is  annotated  inside  the  symbol  by  the  template  name.  A  component  of  a  network  is 
annotated  inside  the  symbol  by  the  corresponding  template  name  and  on  the  outside  by  the 
component  name.  The  example  given  below  shows  a  subsystem  template  called  merge  Its 
components  are  called  al  ,  a2  and  ch  and  are  derived  from  the  templates  act_1 ,  act_2  and 
chan  ,  respectively. 


A  path  is  annotated  by  the  name  of  the  corresponding  access  Interface  and  windows  and  ports  by 
their  local  names: 


port 

identifier 


access  interface 


window 

identifier 


A  subelement  link  is  annotated  with  the  name  of  the  corresponding  subroot  interface  and  the 
active  end  of  the  link  by  its  local  name. 


subelement 

link 

identifier 


subroot 

interface 

\ 

V 

Where  a  component  or  template  possesses  a  template  constant,  the  name,  type  and  value  of  the 
constant  may  be  shown  on  the  diagram. 
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constant 

identifier 


and  the  value  may  be  depicted  as  being  supplied  across  one  or  more  enclosing  boundaries: 


’value' 


data  type 


constant 

identifier 


constant 

identifier 


Annotation  Options 

in  the  sense  of  their  inclusion  in  a  Mascot  diagram,  template  names  and  path  names  are  essential  but 
component  names  and  window/port  names  are  less  important  This  is  especially  so  where  no 
ambiguity  arises  as,  for  example,  where  the  components  are  all  derived  from  different  templates  or 
the  windows  or  ports  of  a  template  or  component  are  of  different  (access  interface)  types 

Extensions 

In  addition  to  the  name  associated  with  an  access  Interface,  it  may  be  considered  desirable  to 
annotate  a  path  by  the  name  of  the  data  objects  and/or  the  type  of  the  data  objects  that  flow  along  the 
path  This  could  be  indicated  by  the  name  of  the  definition  module  which  defines  the  type  of  the 
object 

Port,  window  and  interface  qualifiers  can  also  be  used  to  annotate  the  appropriate  features  of  a 
diagram 

Although  intended  to  denote  only  one  level  of  decomposition  at  a  time,  it  is  sometimes  useful  to  show 
multiple  levels  of  decomposition  in  one  diagram.  The  consequent  increase  in  the  amount  of  information 
to  be  conveyed  would  probably  necessitate  showing  only  a  subset  of  that  available. 

The  Mascot  diagram  can  give  a  one-to-one  representation  of  the  information  contained  in  the 
specification  part  of  a  simple  module.  It  is  therefore  biased  towards  design  expression.  However, 
during  design  derivation,  it  may  be  highly  desirable  to  use  'Mascot-like'  diagrams  which  use  a  subset  of 
the  standard  conventions.  For  example,  a  path  may  be  identified  between  two  components  before 
the  decision  is  made  as  to  which  component  possesses  the  port  and  which  the  window  (which 
possesses  the  'motive  power").  This  is  acceptable. 
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For  information  purposes  only,  it  may  be  desirable  to  generate  Mascot  diagrams  showing  only  a  subset  ot 
the  components  (for  example  omitting  pools  or  channels  or  servers).  Again  this  is  acceptable 
provided  the  diagrams  are  described  as  such. 
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CLASSIFIED  SUMMARY  OF  MASCOT  FEATURES 


Introduction 


The  purpose  of  this  appendix  is  to  provide  a  summary  o'  .0: !’  ■■  Mao  t  '••a’ures  defined  elsewhere  in  the 
KanuuOOk  and  fc  identify  those  parts  o'  ,he  rMirntinn  which  are  nom:  /,r,  m  any  Mascot  3  development 
environment.  These  mandatory  features  have  been  selected  on  the  basis  of  a  standardisation 
philosophy  whose  objectives  are  to  enable  products  to  be  asse^ed  for  conformance  with  the  definition 
and  to  enable  designs  to  be  portable  between  Mascot  deve!opm*>',t  environments  This  philosophy  is 
presented  below 


Philosophy  of  Standardisation 


As  the  first  element  in  the  philosophy  of  standardisation  every  effort  has  been  made  to  define  all  the 
Mascot  features  in  an  unambiguous  manner  Secondly  a  mandatory  subset  of  the  definition  has  been 
identified  This  is  reflected  in  the  order  of  presentation  of  material  in  the  Handbook  sections  on  the 
design  representation  facilities  and  is  summarised  for  reference  at  the  end  of  this  appendix  All  mandatory 
features  must  be  provided  by  any  Mascot  3  development  environment  Where  features  not  included  in 
this  subset  are  implemented,  they  are  required  to  content  to  the  d-.nn.;  on  given  in  the  Handbook 

The  third  element  of  the  philosophy  is.  the  requirement  mar  a  de-.viooment  environment  include 
adequate  linguistic  support  for  the  features-  w>  on  ••  •  op.  -  -.••  i  •••>  vr.ign  representation  language 
used  in  the  Handbook  provides  definitive  guidance  as  *c  wh  •’  n>  >?d  to  be  expressed  but  need 

not  necessarily  be  literally  implemented  The  imauisi.-c  s  ,-.v-  :  tke  the  form  ot  an  Additional 

Features  design  language  ic*  AF  Coral  2  tor  Mascot  2  tor  th*-  nr  .gumming  language  or  languages 
supported  by  the  development  environment  This  should  be  considered  me  preferred  option  as  it  will 
reduce  the  resources  required  to  verify  design  compliance  ot  Mascot  software  and  will  enhance  software 
portability. 

Alternatively,  the  Mascot  3  module  classes  could  be  implemented  >n  a  native  programming  language, 
without  additional  features,  by  a  code  01  practice  In  this  case  me  mop, ore;  ot  each  characteristic  of  each 
module  class  onto  the  programming  tar/;;,  s ;  —  i-i  :  :  ■  ,  .  '  f  the  code  oi  practice.  This 

should  be  done  in  a  form  which  provides  a  smtaMo  ha  a-  tor  ,.••  d  •:  '•••  ;-icj  tot  transporting  a  design 
and  for  design  conformance  checking  or  other  verification  ot  appVa'on  >t?ware  designs 

The  fourth  element  ot  the  philosophy  is  that  module  classes  do  m  need  to  be  supported  in  full.  A 
mandatory  subset  of  characteristics  has  been  defined  for  each  class  Thus  the  definition  contains 
characteristics  which  not  all  development  environments  wilt  implement  even  within  the  mandatory 
classes.  This  element  of  the  philosophy  guarantees  a  minimum  luvei  ot  portability  as  it  defines  the 

i  .  t 
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minimum  characteristics  of  all  Mascot  3  development  environments  It  also  defines  the  minimum  set  ol 
characteristics  which  must  be  provided  for  each  non  mandatory  module  class  implemented  Where  a  non 
mandatory  characteristic  is  supported  it  must  be  supported  in  all  appropriate  module  classes  It  is 
recognised  that  design  authorities  may  wish  to  control  or  restrict  the  use  ot  certain  facilities,  such  as  direct 
data  visibility,  and  therefore  warning  reports  of  their  use  may  be  generated  by  a  development 
environment. 

The  fifth  and  final  element  of  the  philosophy  concerns  extensions  to  Mascot  3.  It  is  recognised  that  the 
definition  cannot  be  maintained,  either  in  scope  or  in  functionality,  in  advance  of  users'  requirements  and 
that  therefore  certain  applications  will  need  facilities  added  to  their  development  environments  that  are 
not  covered  in  the  Mascot  3  definition.  Implementing  a  superset  of  the  facilities,  whilst  not  encouraged,  is 
therefore  permitted  Implementors  must  define  fully  any  extensions  provided  and  must  declare  them  to 
any  testing  authority  so  that  they  may  be  documented  in  a  test  report.  Such  additional  features  must  not, 
of  course,  interfere  with  or  partially  overlap  any  of  the  defined  facilities. 

The  Mandatory  Subset 

The  mandatory  facilities  have  been  divided  into  three  categories:  module  classes,  commands  and 
primitives.  The  mandatory  facilities  specified  below  must  be  provided  by  all  Mascot  3  development 
environments  However,  users  are  not  obliged  to  use  all  the  mandatory  features.  Thus,  for  example,  all 
development  environments  must  support  the  use  of  the  WITH  keyword  within  access  interfaces 
However,  it  is  possible  to  have  a  syntactically  correct  access  interface  which  does  not  use  the  feature 
It  is  net  required  that  support  for  unused  features  be  present  in  target  systems. 

(a)  Module  Classes 

The  diagram  of  Appendix  B  shows  the  complete  set  of  Mascot  module  classes,  the  mandatoiy  subset 
being  highlighted  by  means  of  a  shadowed  font.  All  Mascot  3  development  environments  must  provide 
these  classes.  The  first  of  the  tables  below  specifies  all  the  defined  characteristics  of  the  subset  and 
identifies,  with  an  M  for  mandatory,  those  features  which  it  is  obligatory  to  provide 

The  second  table  specifies  all  the  features  of  the  non-mandatory  module  classes  Mascot  3  development 
environments  which  support  any  of  these  classes  must  provide  support  for  use  of  the  characteristics 
identified  with  an  M 

The  third  table  specifies  the  features  of  particular  module  classes  which  become  mandatory  when  specific 
non  mandatory  features  are  supported. 

(b)  Commands 

It  is  mandatory  to  provide  facilities  for  registration,  introduction,  enrolment,  building,  initialisation  and 
starting  which  accord  with  the  Mascot  definition  They  may  be  provided  in  one  of  two  ways:  either 
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explicitly  through  a  command  interpreter  in  the  torm  shown  in  the  fourth  table  below,  or  by  use  of  other 
user  facilities  such  as  those  provided  by  most  computer  operating  systems.  When  a  command  interpreter 
is  not  being  used  the  documentation  of  the  Mascot  development  environment  must  define  explictly  how 
the  functions  are  provided. 


ir\  Primitive 

There  are  no  mandatory  primitives  in  Mascot  3.  However,  there  are  inter-dependencies  between  the 
primitives  described  in  the  Handbook.  The  fifth  of  the  tables  below  divides  these  primitives  into  sets 
which  are  required  to  be  implemented  together  as  a  group.  It  also  indicates  which  of  the  other  primitive 
groups  are  also  mandatory  for  each  group  supported. 
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1.  CHARACTERISTICS  OF  MANDATORY  MODULE  CLASSES 


MODULE  CLASS 

ACCESS  INTERFACE 


DEFINITION 


IDA 


SERVER 


CHARACTERISTIC 

M  WITH 

M  Procedure  specifications 
Variable  specifications 
Read-only  data  constants 
Qualifiers 

WITH 

Symbolic  constants 
M  Type  definitions 

CONSTANT 
M  PROVIDES 
M  REQUIRES 
WITH 
LIBRARY 
Window  qualifiers 
Port  qualifiers 
M  Data  area 
M  Access  procedures 
Access  data 

M  Window-to-local  equivalence 
Window-to-remote  equivalence 
Window-to  port  equivalence 
Arrays  of  CONSTANTS 
Arrays  of  ports 
Arrays  of  windows 
M  Initialisation  procedure 
Reset  procedure 
Termination  procedure 

CONSTANT 
M  PROVIDES 
M  REQUIRES 
WITH 
LIBRARY 
Window  qualifiers 
Port  qualifiers 
M  Data  area 
Handler 

M  Access  procedures 
Access  data 

M  Window-to-local  equivalence 
Window-to-remote  equivalence 
Window-toporl  equivalence 
Handler-to-interrupt  connection 
Arrays  of  CONSTANTS 
Arrays  of  ports 
Arrays  of  windows 
M  Initialisation  procedure 
Reset  procedure 
Termination  procedure 
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ACTIVITY 


CONSTANT 
M  REQUIRES 
WITH 
LIBRARY 

Port  qualifiers 
Arrays  of  CONSTANTS 
Arrays  of  ports 

SUBSYSTEM  CONSTANT 

M  PROVIDES 
M  REQUIRES 
M  USES 

Window  qualifiers 
Port  qualifiers 
Arrays  of  CONSTANTS 
Arrays  of  ports 
Arrays  of  windows 
Library  instantiation 
M  IDA  components 
M  SERVER  components 
M  ACTIVITY  components 
M  SUBSYSTEM  components 
M  Window-to  -window  equivalence 
Window-to-port  equivalence 

SYSTEM  CONSTANT 

M  USES 

Library  instantiation 
M  IDA  components 
M  SERVER  components 
M  ACTIVITY  components 
M  SUBSYSTEM  components 
Arrays  of  CONSTANTS 
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COMPOSITE  ACCESS  INTERFACE  M  COMPRISES 


SUBROOT  INTERFACE 

M 

WITH 

M 

Procedure  specifications 
Variable  specifications 
Read-only  data  constants 

LIBRARY  INTERFACE 

M 

WITH 

Procedure  specifications 
Read-only  data  constants 

COMPOSITE  IDA 

CONSTANT 

M 

PROVIDES 

M 

REQUIRES 

M 

USES 

Window  qualifiers 

Port  qualifiers 

Arrays  of  CONSTANTS 

Arrays  of  ports 

Arrays  of  windows 

Library  instantiation 

M 

IDA  components 

M 

Window-to-window  equivalence 
Window-to-port  equivalence 

COMPOSITE  ACTIVITY 

CONSTANT 

M 

REQUIRES 

M 

USES 

Port  qualifiers 

Arrays  of  CONSTANTS 

Arrays  of  ports 

Library  instantiation 

M 

ROOT  components 

M 

SUBROOT  components 

ROOT 

CONSTANT 

M 

REQUIRES 

M 

NEEDS 

WITH 

LIBRARY 

Port  qualifiers 

Arrays  of  CONSTANTS 

Arrays  of  ports 
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SUBROOT 


CONSTANT 
M  REQUIRES 
M  GIVES 
M  NEEDS 
WITH 
LIBRARY 
Port  qualifiers 
Arrays  of  CONSTANTS 
Arrays  of  ports 


COMPOSITE  SUBROOT  CONSTANT 

M  REQUIRES 
M  GIVES 
M  NEEDS 
M  USES 

Port  qualifiers 
Arrays  of  CONSTANTS 
Arrays  of  ports 

M  SUBROOT  components 
Library  Instantiation 

LIBRARY  CONSTANT 

GIVES 

WITH 

LIBRARY 

Arrays  of  CONSTANTS 

COMPOSITE  SERVER  CONSTANT 

M  PROVIDES 
M  REQUIRES 
M  USES 

Window  qualifiers 
Port  qualifiers 
Arrays  of  CONSTANTS 
Arrays  of  ports 
Arrays  of  windows 
Library  instantiation 
M  IDA  components 
M  SERVER  components 
M  Window-to-window  equivalence 
Window-to-port  equivalence 
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MANDATORY  GR 


Group  Name 

COMPOSITE  ACTIVITY 

COMPOSITE  SUBROOT 

LIBRARY 


PUPS  OF  MASCOT  3 
Group 

COMPOSITE  ACTIVITY 
SUBROOT  INTERFACE 
ROOT 
SUBROOT 

COMPOSITE  SUBROOT 


LIBRARY  INTERFACE 
LIBRARY  template 


MODULE  CLASSES 


Requirements 

Implement  as  a  group 


Implement  COMPOSITE 
ACTIVITY  group 

Support  keyword 
LIBRARY 
Support  library 
instantiation  at  least  in 
SYSTEM 
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Group 


Status  progression 


REGISTER 

INTRODUCE 

ENROL 


Building  BUILD 

Execution  Control  INITIALISE 

START 
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Group  Name 

Graua 

Other  Groups  Required 

Control  Queue 

JOIN 

LEAVE 

WAIT 

STIM 

Checking 

CHECK 

Control  Queue 

Basic  Interrupt 

STIMINT 

ENDHANDLER 

Control  Queue 

Interrupt  Connection 

CONNECT 

Basic  Interrupt 

Interrupt  Disconnection 

DISCONNECT 

Interrupt  Connection 

Timing 

TIMENOW 

DELAY 

Timeout 

WAITFOR 

Control  Queue 

Timing 

Co-operative  Scheduling 

SUSPEND 

Activity  Termination 

ENDROOT 

Error  Handling 

GETERROR 

ERROR 

FATALJERROR 

Monitoring 

SELECT 

EXCLUDE 

RECORD 

Execution  Control 

HALT 

RESUME 

START 

TERMINATE 

RESET 

If  any  primitive  in  a  group  is  implemented  then  all  primitives  in  that  group  and  in  any  ’groups  required'  must 
be  implemented. 
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MASCOT  GLOSSARY 


Access  Interface  A  specification  defining  the  possible  interactions 

(eg  procedure  specifications)  between  the  components  connected  by  a  path.  In  its  composite 
form  it  comprises  a  set  of  other  access  Interfaces. 

Access  Procedure  A  procedure,  implemented  in  an  IDA  or  server,  and 

corresponding  to  a  procedure  heading  specified  in  an  access  interface  to  which  a  window 
specification  of  the  IDA  or  server  refers.  It  provides  a  network  interaction  along  a  connected  path  of 
the  appropriate  type. 

Activity  The  Mascot  design  entity  representing  a  single 

independent  information  processing  element.  An  activity  module  is  a  template  which  may  be  used 
to  create  activity  components  each  of  which  is  an  independently  scheduled  single  sequential 
program  thread,  conceptually  executing  in  parallel  with  other  activities.  An  activity  usually  specifies 
one  or  more  ports  each  of  which  defines  a  connection  to  be  established  from  the  activity  to  a 
window  on  a  neighbouring  component  in  the  execution  environment.  A  composite  form  of 
activity  is  provided  for  sequential  program  decomposition  in  terms  of  subelements  known  as  roots 
and  subroots. 

Building  The  process  by  which  executable  software  is  created 

from  its  defining  templates,  which  must  have  achieved  fully  enrolled  status 

Channel  A  special  case  of  an  IDA  having  destructive  read 

properties.  The  channel  provides  facilities  for  transmission  of  information. 

Class  The  category  of  a  Mascot  design  entity  Design 

entities  are  grouped  into  specifications  and  templates  Specifications  comprise  the  classes: 
access  Interface,  subroot  Interface,  library  Interface  and  definition  Templates 
comprise  the  classes:  system,  subsystem,  activity,  channel,  pool,  IDA.  server,  root, 
subroot  and  library. 

Component  A  constituent  of  a  composite  template  The  type 

of  a  component  is  identified  by  the  name  of  the  template  which  is  used  in  the  definition  of  the 
component. 
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Composite  A  composite  module  is  one  which  is  further 

decomposed  in  terms  of  lower  level  modules.  For  specifications  the  decomposition  is  in  terms  of 
the  same  class  of  specification.  For  templates  the  decomposition  depends  on  the  class  of  the 
template.  The  only  specification  with  a  composite  form  is  the  access  Interface.  The  following 
templates  have  composite  forms:  system,  subsystem,  IDA,  server,  activity,  subroot. 

Context  That  part  of  the  executable  software  which  supports 

(but  is  not  part  of)  the  application  software  defined  by  the  system  template,  it  implements  the 
facilities  specified  in  the  context  Interface. 

Context  Interface  A  special  form  of  specification  which  defines  the 

facilities  offered  (implicitly)  by  the  context  to  all  applications  modules.  It  is  usually  a  collection  of 
other  specifications. 

Control  Queue  An  object,  declared  in  an  IDA,  which  may  be  operated 

upon  by  a  set  of  primitives  to  ensure  mutual  exclusion  and  cross-stimulation  between  activities.  The 
relevant  primitives  are  CHECK,  JOIN,  LEAVE,  STIM,  STIMINT,  WAIT,  WAITFOR. 

Definition  A  specification  defining  a  set  of  data  types  and 

named  constants  for  use  by  simple  Interfaces  and  simple  templates.  It  may  refer  to  other 
definition  modules. 

Element  A  fundamental  Mascot  design  entity:  simple 

activity,  simple  IDA,  simple  server,  composite  activity. 

Enrol  The  enrol  operation  checks  that  the  name  part, 

specification  part  and  implementation  part  of  a  template  module  have  been  defined  and 
are  legal.  It  may  involve  using  information  in  the  specification  parts  of  the  modules  to  which  it 
refers  If  the  checking  is  successful,  then  the  module  will  be  accorded  partially  or  fully  enrolled 
status,  depending  upon  the  type  of  the  module  itself  and  on  the  status  of  the  modules  to  which 
it  refers. 


Fully  Enrolled  A  status  value  achieved  by  a  template  module  as 

a  result  of  a  successful  enrol  operation.  For  a  composite  template,  the  status  indicates  that  all 
the  templates  which  define  the  module's  components  have  also  achieved  fully  enrolled 
status. 
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Fully  Introduced  A  status  value  achieved  by  a  module  as  the  result 

of  a  successful  Introduce  operation.  The  status  indicates  that  all  specification  modules 
referred  to  in  the  module's  specification  part  have  also  achieved  fully  introduced  status 

Handler  A  routine  invoked  as  a  direct  consequence  of  a 

hardware  interrupt.  All  handlers  are  located  within  servers. 

IDA  The  Mascot  design  entity  representing  a  passive 

independent  information  storage  or  information  transmission  element.  In  the  simple  form  it  contains 
both  shareable  data  and  the  access  mechanisms  which  can  operate  on  this  data;  these  access 
mechanisms  safeguard  the  integrity  of  information  within  or  passing  through  an  IDA  and  sustain 
information  propagation  for  intercommunication  between  activities.  An  IDA  module  is  a  template 
which  may  be  used  to  create  IDA  components  each  of  which  allows  several  independently 
scheduled  single  sequential  program  threads  to  be  simultaneously  active  or  suspended  within  the 
IDA.  An  IDA  specifies  one  or  more  windows  defining  the  connections  which  can  be  established  from 
ports  on  neighbouring  components  in  the  execution  environment.  An  IDA  may  also  specify  ports 
each  of  which  defines  a  connection  to  be  established  from  the  IDA  to  a  window  on  a  neighbouring 
component;  such  ports  allow  data  to  be  projected  from  one  IDA  to  another  with  no  intervening 
activity.  A  composite  form  of  IDA  is  provided  for  network  decomposition  in  terms  of  internal  IDAs. 

Implementation  part  The  part  of  a  template  module  which  defines  the 

internal  details  of  the  template.  For  simple  templates  it  defines  the  data  and  algorithms  together 
with  references  to  the  required  definitions  and  library  interfaces  For  composite  templates  it 
defines  the  components  and  their  interconnections.  For  simple  templates  this  corresponds  to 
the  information  necessary  to  achieve  fully  enrolled  status  For  composite  templates  it 
corresponds  to  the  information  required  to  achieve  at  least  partially  enrolled  status. 

Interface  A  specification  for  a  connection  between  two 

components  There  are  three  types  of  interlace  access  Interface,  library  Interface,  subroot 
Interface.  An  interface  may  refer  to  one  or  more  definitions  to  import  supplementary 

specifications 

Introduce  The  introduce  operation  checks  that  the  name  part 

and  specification  part  of  a  module  have  been  defined  and  are  legal  If  the  checking  is 
successful,  then  the  module  will  be  accorded  partially  or  fully  introduced  status,  depending 
upon  the  status  of  the  modules  to  which  it  refers  in  its  specification  part 
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Library  The  Mascot  design  entity  implementing  the  set  of 

procedures  specified  in  one  or  more  library  Interlaces.  This  module  supports  procedural 
decomposition  of  simple  templates  and  must  be  capable  of  multi  threaded  operation.  It  differs  from 
an  IDA  which  is  also  multi  threaded  in  that  there  is  no  interaction  between  the  threads. 

Library  Interface  A  simple  specification  defining  the  operations 

which  a  library  makes  available  to  any  simple  template. 

Link  A  control  flow  connection  from  one  subelement  to 

another.  Its  diagrammatic  representation  is  a  line  which  carries  a  hollow  arrowhead  to  indicate  the 
direction  of  invocation.  The  type  of  a  link  is  a  subroot  Interface  which  defines  the  nature  of  the 
interactions  between  these  subelements. 

Mascot  Database  The  collection  of  all  Mascot  modules,  their  status 

and  their  derived  products  known  to  a  particular  support  environment. 

Module  A  textual  unit  (or  possibly  a  set  of  such  units) 

representing  a  specification  or  a  template.  It  possesses  an  explicit  class  which  reflects  its 
contents  In  their  completed  form,  all  classes  of  module  have  a  name  part  and  a  specification 
part,  and  in  addition  the  template  modules  have  an  Implementation  part. 

Name  part  The  section  of  a  module  which  defines  the  class 

and  name  of  the  template  or  specification  which  the  module  represents. 

Network  A  set  of  interconnected  Mascot  components 

(elements  and  other  networks)  which  constitutes  the  whole  (system)  or  part  (subsystem, 
composite  IDA,  composite  server)  of  a  Mascot  application 


Partially  Enrolled  A  status  value  given  to  a  composite  template 

module  for  which  the  enrol  operation  was  successful,  but  which  failed  to  achieve  fully  enrolled 
status  It  indicates  that  at  least  one  of  the  templates  which  define  the  module's  components 
has  not  yet  achieved  fully  enrolled  status. 

Partially  Introduced  A  status  value  given  to  a  module  for  which  the 

Introduce  operation  was  successful,  but  which  failed  to  achieve  fully  introduced  status  It 
indicates  that  at  least  one  of  the  specification  modules  referred  to  in  its  specification  part  has 
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not  yet  achieved  fully  introduced  status. 


Path  A  data  flow  connection  between  a  port  of  one 

component  and  a  window  of  another.  Its  diagrammatic  representation  is  a  line  which  normally 
carries  a  solid  arrowhead  to  indicate  the  direction  of  data  flow.  The  type  of  a  path  is  an  access 
interface  which  defines  the  nature  of  the  interactions  between  these  components.  A 
composite  form  of  path  is  available,  where  the  type  of  the  path  is  a  composite  access 
interface 

Pool  A  special  case  of  an  IDA  having  destructive  write 

properties.  Data  in  a  pool  is  overwritten  on  a  write  operation  but  may  be  read  repeatedly. 

Port  A  named  reference  to  an  access  Interface  by 

means  of  which  a  template  expresses  its  requirement  for  interactions  with  other  templates. 
Externally  it  expresses  a  connectivity  constraint  of  the  template.  Internally,  the  port  name  is  used  as 
a  means  of  selecting  between  ports.  A  port  is  the  active  end  of  a  path.  Its  diagrammatic 
representation  is  a  small  filled  circle  on  the  boundary  of  a  component.  A  composite  form  of  port  is 
available. 


Registered  A  status  value  indicating  that  the  name  part  of  a 

module  has  been  defined  and  is  legal. 

Root  The  Mascot  design  entity  representing  the 

subelement  which  contains  the  initial  entry  point  of  a  composite  activity.  A  root  usually  specifies 
one  or  more  subroot  Interfaces  which  define  connections  to  be  established  to  subelement 
components  in  the  same  activity.  A  root  may  also  specify  one  or  more  ports  each  of  which 
defines  a  connection  to  be  established  from  the  root  component  to  a  port  of  the  enclosing 
activity.  A  root  module  is  a  template  which  may  be  used  to  create  root  components. 

Server  The  Mascot  design  entity  representing  a  single 

independent  device  handling  element;  it  is  the  only  form  of  design  entity  which  can  be  used  for  this 
purpose.  It  has  all  the  features  of  an  IDA  and  in  addition  may  contain  one  or  more  handler  routines  to 
be  invoked  as  a  direct  consequence  of  hardware  interrupts.  A  server  module  is  a  template  which 
may  be  used  to  create  server  components  each  of  which  allows  several  independently  scheduled 
single  sequential  program  threads  to  be  simultaneously  active  or  suspended  within  the  server.  A 
composite  form  of  server  is  provided  for  network  decomposition  in  terms  of  internal  servers  and 
IDAs 
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Simple  A  simple  module  is  one  which  is  not  further 

decomposed  in  terms  of  lower  level  modules  Some  templates  and  all  specifications  have  a 
simple  form  which  is  described  in  detail  under  the  appropriate  heading. The  following  templates 
have  simple  tonus:  activity,  IDA,  server,  root,  subroot,  library. 

Specification  A  module  defining  an  Interface  or  definition  All 

have  a  simple  form  but  only  an  access  Interface  may  be  composite. 

Specification  part  The  part  of  a  module  which  specifies  the  external 

view  of  the  template  or  specification  which  it  represents  In  the  case  of  a  specification,  it 
completes  the  module.  In  the  case  of  a  template,  it  contains  sufficient  information  for 
components  of  that  type  to  be  included  in  a  composite  template.  It  also  constrains  the 
implementation  part.  It  corresponds  to  the  information*  required  to  achieve  at  least  partially 
introduced  status. 

Status  An  attribute  associated  with  a  module  indicating  the 

degree  of  progress  made  in  the  definition  and  checking  of  the  module  and  of  any  other  modules  to 
which  it  refers,  and  hence  indicating  its  fitness  for  use  by  other  modules.  Five  status  values  are 
defined:  registered,  partially  introduced,  fully  introduced,  partially  enrolled  and  fully 
enrolled. 

Subelement  A  Mascot  entity  supporting  sequential  decomposition 

of  an  element  or  subelement  (ie  a  root  or  subroot). 

Subroot  The  Mascot  design  entity  representing  a 

subelement.  A  subroot  specifies  a  single  subroot  interface  defining  the  connections  which  may 
be  established  from  other  subelement  components  in  the  same  activity.  A  subroot  may  specify 
one  or  more  subroot  interfaces  which  define  connections  to  be  established  to  other 
subelement  components  in  the  same  activity.  A  subroot  may  also  specify  one  or  more  ports 
each  of  which  defines  a  connection  to  be  established  from  the  subroot  component  to  a  port  of  the 
enclosing  activity.  A  subroot  module  is  a  template  which  may  be  used  to  create  subelement 
components.  A  composite  form  of  subroot  is  provided  for  decomposition  in  terms  of  internal 
subroots. 

Subroot  Interface  A  simple  specification  defining  the  possible 

interactions  (eg  procedure  specifications)  between  the  components  connected  by  a  link. 


Appendix  F  Glossary 


F-  6 


Mascot  Version  3.1 


Subsystem  A  network  representing  pan  of  a  Mascot  application 

Subsystems  may  possess  both  ports  and  windows  and  may  therefore  communicate  directly  with 
each  other  Where  a  subsystem  contains  no  activity,  either  directly  or  indirectly,  it  is  functionally 
identical  to  a  composite  IDA  or  a  composite  server 

System  A  network  representing  the  outermost  level  of 

software  description.  When  supported  by  all  the  modules  referred  to  explicitly  or  implicitly,  it 
constitutes  a  complete  Mascot  application  software  description 

Template  A  pattern  from  which  components  may  be  created 

during  building  The  creation  of  these  components  is  controlled  by  definitions  within  composite 
templates. 

Template  Constant  A  constant,  named  in  the  specification  part  of  a 

template,  for  use  within  the  implementation  part  its  value  is  usually  supplied  when 
components  to  be  created  from  the  template  are  named  in  a  (higher  level)  composite 
template  In  the  case  of  a  system  template,  the  value  is  supplied  as  part  of  the  building 
process 

Window  A  named  reference  to  an  access  interface  by 

means  of  which  a  template  expresses  the  interactions  it  provides  for  use  by  other  templates 
Externally,  it  expresses  a  connectivity  constraint  of  the  template  Internally,  the  window  name  is 
used  as  a  means  of  allocating  internal  features  between  windows  A  window  is  the  passive  end  of  a 
path  Its  diagrammatic  representation  is  a  small  filled  rectangle  on  the  boundary  of  a  component  A 
composite  form  of  window  is  available 
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